home *** CD-ROM | disk | FTP | other *** search
/ Club Amiga de Montreal - CAM / CAM_CD_1.iso / files / 568a.lha / compress.library_v1.0 / compress_lib.doc.pp / compress_lib.doc
Encoding:
Text File  |  1991-11-03  |  6.2 KB  |  112 lines
  1.                              compress.library
  2.                                 Version 1.0
  3.                             (C) 1991 Bryan Ford
  4.  
  5.     First let's get the legaleze over with.  The compress.library (or
  6. at least *this* (my) compress.library) is not public domain.  However, it
  7. can be freely copied for noncommercial purposes.  You may distribute it on
  8. its own, or with another program (i.e. one that uses the compress.library)
  9. as long as that program is also freely distributable.  In any distribution,
  10. alone or with another program, this document must accompany the
  11. compress.library itself.  The programmer's files (in the "programmers"
  12. directory) do not need to be included when the compress.library is included
  13. with another program, but they must be included with any stand-alone
  14. distribution of the compress.library.  If you would like to distribute the
  15. compress.library with a commercial program, you must make arrangements with
  16. me first.  (Don't worry, I'm not planning on bleeding anybody dry.)
  17.  
  18.     Now on to the fun part.  The compress.library is a very small
  19. run-time library intended for general use by other programs.  Its purpose
  20. is to take a chunk of data given to it by a program, compress it
  21. "losslessly", and pass the compressed data back to the application.  Later,
  22. the application can call on the compress.library to expand the data into
  23. its original shape and size.
  24.  
  25.     The data can be anything the program wants, and does not even need
  26. to reside on disk or be anything related to a "file".  Therefore, it could
  27. be used for "stashing" a program's data in memory while the user is in some
  28. other part of the program.  Or it could be used simply for real-time
  29. compression and decompression of a program's data.  (Can you say
  30. "Aquarium"?) Or maybe we could persuade Matt Dillon to compress data blocks
  31. as DNET sends them over the modem...  I'm sure programmers could find many
  32. uses for a general-purpose compressor such as this.
  33.  
  34.     You are probably by now quite skeptical about the practical value
  35. of something like this, with the delays incurred by compression and/or
  36. decompression.  Don't worry, the compress.library is very fast, in both
  37. compression and decompression.  On a stock 68000 Amiga, it compresses data
  38. at over 16K/sec and decompresses at over 32K/sec.  (Both of these figures
  39. are probably significantly underestimated, since I've done quite a bit of
  40. optimization since I timed them on a 68000.) On my 25MHz A3000 I recently
  41. benchmarked the code at 120K/sec compression 270K/sec decompression!
  42. Faster decompression is possible (I believe the Imploder decompresses more
  43. quickly for example), but usually compression speed must be sacrificed.  My
  44. intention is to provide both compression and decompression at near
  45. real-time speeds.  With small chunks of data, compression and decompression
  46. are often not noticeable at all.
  47.  
  48.     Now then, how well does it compress?  See for yourself:  Load up
  49. Zoo 2.00 (I haven't tried Zoo 2.10 yet) and try compressing a few things
  50. with it.  The compress.library uses almost the same algorithm as Zoo (a
  51. variation of LZW compression), and gets almost identical compression
  52. ratios.  (Often slightly better, depending on the number of bits selected.)
  53. And, of course, the compress.library leaves Zoo in the dust in terms of
  54. speed.  Programs like PkZip and Lharc (LZ) get better compression ratios,
  55. but at a great cost in speed.
  56.  
  57.     The compress.library does require a small amount of extra memory
  58. during compression and decompression.  (It will return an error to the
  59. calling program if the memory is not available.) The amount of memory used
  60. depends on the number of bits used in the LZW algorithm.  The
  61. compress.library can be set to use anywhere between 9 and 15 bits.  The
  62. default is 12, which requires about 25K during compression and about 12K
  63. during decompression.  For every extra compression bit you add on, you
  64. roughly double the memory requirement for both compression and
  65. decompression.  The application has the option of setting the number of
  66. compression bits, or it can just use the default.
  67.  
  68.     So, how do you use the compress.library in your programs?  Look in
  69. the file "compress_lib.prodoc" in the "programmers" directory.  I purposely
  70. kept the interface very simple and direct, so you should have no problem
  71. using the library.
  72.  
  73.     Note that I named this library "compress.library" rather than
  74. "bryanscompress.library" or somesuch for a good reason.  This is intened
  75. not just as a stand-alone piece, but as the first implementation of a
  76. standard library interface.  I want to encourage other people to come up
  77. with alternate compression libraries, maybe with different compression
  78. ratio/speed tradeoffs.  I tried to strike a good balance between speed and
  79. compression, but users with different systems might have different
  80. priorities.  Decompression could be sped up by sacrificing compression
  81. speed.  (Good if you do mostly reading of once-compressed data.) Better
  82. compression ratios could be gotten with a slower algorithm.  (Maybe
  83. Jonathan Forbes would like to make a compress.library that uses LZ's
  84. code...?)
  85.  
  86.     Multiple compression libraries (and therefore multiple data
  87. formats) floating around could create a slight problem, though, if we start
  88. seeing programs distributed with data already compressed using a particular
  89. compress.library - the user might want to use a different library than the
  90. one the data was compressed with.  Although a library will (or at least
  91. should) always detect a "foreign" data format that it can't decompress, and
  92. therefore shouldn't crash the machine or scramble data, it still creates
  93. lots of trouble.  Therefore, I think we should keep use of the
  94. compress.library to the individual:  distribute a program (and its data) in
  95. uncompressed form, then let the user tell the program how to compress its
  96. data, which library to use, etc.  Since freely distributable programs are
  97. usually distributed in compressed form anyway, there would not be
  98. significant gains to distributing already-compressed data anyway.
  99.  
  100.     So, there you go - let's see what exotic ways to use compression
  101. you can come up with.  I can be contacted for comments, suggestions, or
  102. flames at any of the addresses below.
  103.  
  104.     Bryan Ford
  105.     27104 Ballif Hall
  106.     Salt Lake City, UT 84112
  107.     (801) 585-4619
  108.     baf0863@cc.utah.edu
  109.     baf0863@utahcca.bitnet
  110.  
  111. Have fun!
  112.