Hi Eric, I can't speak about the Morph related aspects, not my area of expertise.
The other aspects, about the actual read/writer, all sound reasonable. It would be very good if someone contributed to improve the quality of GIFReadWriter, thanks for doing this ! One remark though, I think that your changes are based off Pharo 6. That is a problem because GIFReadWriter underwent a couple of changes in relation to stream/file handling. I see some small conflicts in #readHeader, nothing major. I also assume the transcript printing will be removed eventually. Normally development takes place in Pharo 7 with an option to back port to Pharo 6.1 if it is a very important change. These kind of discussions also normally happen on the pharo-dev mailing list. Thanks again and please continue. Sven PS: maybe you can find a GIF test suite somewhere like there exists one for PNG (https://pharo.manuscript.com/f/cases/21927/Figure-out-why-PNGReadWriter-does-not-pass-a-full-test-suite and https://github.com/DraagrenKirneh/PngSuiteExplorer). > On 23 May 2018, at 21:08, Eric Gade <eric.g...@gmail.com> wrote: > > Hello all, > > Please excuse the length of this email. > > A week or two ago I discovered that the GIF implementation in Pharo (and > possibly Squeak?) is incomplete. This has two side effects: > 1) Not all GIF data will load correctly; > 2) There is for now no way to display animated GIFs. > > It looks like the corresponding classes have not been updated since the 90s. > > But fear not! I've been working on a solution, and need the community's > feedback and advice. > > # The Problem with GIFs # > One of the issues here is that GIF files can (and do) contain multiple images > inside of them. The root header will supply things like a "screen size" in > which these nested images should be displayed. That also means that each > nested image does not have to have the same dimensions as the parent object > -- in fact, most are offset somewhere inside of the "screen." > > Additionally, each nested image will contain information about how it should > be handled when animating. This is a crucial point. In many cases images are > just updates of a small area that should be applied to the previous image in > the set. GIFs call this attribute the "disposal," and this information is > contained in a packed byte. > > Both GIFReadWriter and AnimatedGIFReadWriter have intentionally > skipped/ignored the bits/bytes that store and keep track of these things. > GIFReadWriter on its own will only read the first Form and does not store > information about disposal, offsets, etc. These classes are not reading all > the information we need to display GIFs! > > # My Solution # > The attached changes file includes some preliminary updates to the > GIFReadWriter class. Now when each nested image is read, it will be loaded > into a collection called "frames" as a (new -- see attached package file) > AnimatedImageFrame. Instances of this new class will store the disposal > symbol, offset, and form for each nested image in the file. > > I have also created an AnimatedImageMorph which reads AnimatedImageFrame > objects and cycles them based on the disposal re-drawing rules. > > # Trying This Out # > To try this out, first load the attached changes file and the ST file. > > You'll need a FileReference to a gif file, so when you have one execute the > following: > > ```smalltalk > file := "your gif filereference here" > img := AnimatedImageMorph fromGIFReader: (AnimatedGIFReadWriter > formsFromStream: file readStream). > img openInWorld. > ``` > > # Issues # > Not all GIF images work. This has to do with my implementation of the > disposal (redrawing) rules for each frame. I'm still experimenting. > > I believe AnimatedGIFReadWriter should be deprecated and all appropriate > functionality should be put into GIFReadWriter. If you all agree, I will make > several changes to GIFReadWriter that I think will be helpful / necessary. > > AnimatedImageMorph is also incomplete. I'm not sure if I should subclass > ImageMorph for this or not. > > # Your Feedback # > If you disagree with any point of this architecture, please let me know. Also > if you come across GIFs that do not animate or display properly, send them my > way please! > > -- > Eric > <Images-Animated.st><GIFReadWriter.EricGade.cs>
