The original KOLGif package was based on code from the famous RxLib library. But by dragging and dropping the code, I reduced my work, giving up compression and keeping only decompression. I did this for several reasons.

The first is the licensed purity of the product. As you know, any commercial project must deduct a certain (small, true) amount in favor of the patent owners. Not that I felt sorry for this money (especially not for my own, since I do not deal with commercial products), I just consider such a requirement unlawful, as well as the patent system itself - a brake on progress. / I think it's just unethical to trade in knowledge. Imagine, as an analogy, that a college degree could be bought on the market. /

The second consideration is the amount of source code. The smaller it is, the easier it is to understand, debug, fix all errors. By the way, in the RxLib code such errors, although not fatal, were also found and eliminated by me during the adaptation of the code to the KOL requirements. (Which ones, I can't remember now, rather, these were not errors, but shortcomings that led to incorrect display of some GIF images).

The third is the quality of the compression. More precisely, the inability to control and improve it without the use of special methods. Let me explain what I'm talking about now. As you know, there are various software products that can create GIF images from other types of images. It is known that the result is a completely different size GIF-files, that is, the quality of compression is determined by a rather fine selection of parameters. The quality of compression, for example, provided by the RxLib library code (in turn borrowed from others by the author, as indicated in the library text), leaves much to be desired. And I'm not ready to write my own code that can compete with other GIF compressors and optimizers. It is both more honest and more convenient to give up this possibility right away (why make a code that is obviously the worst known analogs?).

However, if anyone wishes to complete the conversion or make their own compressor for Gif by extending KOLGif, I have no particular objection to that.

 

I note right away that the code of the KOLGif module is multivariate, and is compiled differently depending on the conditional compilation symbols declared in the project options.

Namely, it may or may not use the Animation module (symbol USE_ANIMATION_OBJ). If used, the TGif object does not inherit directly from TObj, but from TAnimation. The only purpose of such a change in the position in the type hierarchy is the ability to use the universal visual object TAniShow, capable of displaying (practically - with the same code) not only GIF images, but also frames compiled programmatically from TBitmap bitmaps and, in general, any objects inherited from TAnimation. For example, there is my implementation of TFlic, a successor from it, which provides decoding of AutoDesk animation files (FLIC files).

Another acceptable variation is the ability to abandon your own (converted from RxLib) GIF decoder, and use the KOLGraphicCompression module from the KOLGraphic package (USE_KOLGRAPHIC conditional compilation symbol) for this purpose. Experiments have shown that the difference can be observed only on a very small number of GIF images, moreover, most often, encoded in clear violations of the GIF format conventions, or simply flawed. Moreover, only one of these two compressors does not always win. As for the size of the final code added to the application, KOLGraphic, as a more versatile package, adds a lot more to the weight of the program. It should be used for GIF decompression only if this package is already used in the application to work with one or several other graphic formats:

 

I.GIF decoder (TGifDecoder). The TGifDecoder object can be used on its own if all you need is to decode individual frames of a GIF animation, decode the first frame, or decode a single frame of a non-animated GIF image. In this case, a minimum of compiled code will be added to the application. I hope you can figure out its properties and methods on your own, they are quite simple, provided with comments and do not require special explanations.

II.Frame object (TGifFrame). This object is a helper object, and is used in the TGif object implementation to represent individual frames of an animated GIF image. You have to resort to its properties very rarely if you want to analyze individual frames or provide some information for the user on them.

III.Main object (TGif). The TGif object type provides all the basic functionality for working with animated GIFs. For example, it can draw the current frame (methods Draw, DrawTransp, DrawTransparent, StretchDraw, StretchDrawTransp, StretchDrawTransparent), control frame switching (the Frame property), as well as load and decode the entire GIF image. But it does not provide time tracking to animate the image correctly.

IV.Visual animation of the Gif image in the window (TGifShow). The TGifShow visual object is inherited from the main visual object of the KOL package - from TControl. It switches frames on its own, updating the animation on screen whenever possible when its Animate property is set to TRUE. / As I already said, instead of it there is an opportunity to use the TAniShow object from the Animation module, while other formats of animated images become available.