[squeak-dev] [Discussion] GIF and Animated GIF Refactoring

Eric Gade eric.gade at gmail.com
Sun Nov 28 16:31:17 UTC 2021

Hi Christoph,

On Sat, Nov 27, 2021 at 2:12 PM Thiede, Christoph <
Christoph.Thiede at student.hpi.uni-potsdam.de> wrote:

>    - compatibility checks - are there any breaking changes in terms of
>    behavior, or has the public protocol been changed? Maybe it would be worth
>    improving compatibility, adding a few "deprecated" methods, autc. For
>    instance, probably we should re-add an empty subclass AnimatedGIFReadWriter
>    in the 60Deprecated/61Deprecated package to not break existing code that
>    relies on it. Another example, #openGIFInWindow:/#fromStream: are not
>    understood by BetterAnimatedImageMorph class.
I agree. None of this replacement should happen without preserving that
polymorphism, at least for the time being. I should probably write a few
tests along the way (I have only a handful from previous ports)

>    - code review - not sure whether there is anyone who would like to
>    have a detailed look at your patch before it is integrated. But as you say
>    it is "tested by the crowd" on two different Smalltalk systems, my personal
>    opinion would be that this should not be a reason to block great
>    contributions.
I believe I have some tests in ports to the other Smalltalks but I'll
probably have to refactor them. In particular, there is and should be a
test for reading a GIF, writing it out, reading it back in, and having the
correct pixels at expected locations.

PS: Have you or someone else already tried to optimize the new
> GIFReadWriter for performance? I am having a 36 MB large GIF
> <https://github.com/LinqLover/TelegramSmalltalkBot/blob/master/img/screencast.gif>
> here which takes eternities (> 10 minutes) to file in on my machine. With a
> 9 MB small GIF, it still takes a few minutes. And the RAM consumption of my
> image is noticeably high. But after that, I can play the GIF with ca. 25
> FPS. However, the old implementation was not faster either.

It's actually worse than you think -- I cannot spy on the process of
parsing your large GIF file without my Squeak process eventually killing
itself, probably due to memory consumption. As it stands, I don't know the
exact reason the memory consumption is so high. There *must* be some places
for optimization in the decoding. When I rewrote the LZW encoding/decoding
portions of this, my immediate goal was to understand what was going on --
therefore being verbose and using more objects. I am very likely using
inappropriate classes or data structures for some of the decoding. Worse
case scenario: we offload the encoding/decoding of LZW data to a plugin.

There is also the matter of working with the Bitmap and Form objects at a
low level, which I must admit I still don't fully grasp. I could be missing
something there.

That said, are there other packages available for profiling etc, or is
MessageTally class >> spyOn: the bread and butter for that kind of thing?

On a related note, I did notice that during GIF frame composition there was
what seemed to me a lot of time spent on symbol/string comparison at one
point. (`9.5% {192ms} ByteSymbol(Symbol)>>=`). I don't quite understand why
that should be the case.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211128/f8690327/attachment.html>

More information about the Squeak-dev mailing list