Thanks, Sven. I'll switch over to Pharo 7a and continue my efforts there. When I have something worth a damn I'll submit a PR according to the new contribution protocol.
On Wed, May 23, 2018 at 4:44 PM, Sven Van Caekenberghe <s...@stfx.eu> wrote: > 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> > > > -- Eric
