<div dir="ltr"><div>Hi Christoph,</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Nov 27, 2021 at 2:12 PM Thiede, Christoph <<a href="mailto:Christoph.Thiede@student.hpi.uni-potsdam.de">Christoph.Thiede@student.hpi.uni-potsdam.de</a>> wrote:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-3387757843769282171divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
<p></p>
<ul style="margin-bottom:0px;margin-top:0px">
<li><span>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 <span>AnimatedGIFReadWriter in the 60Deprecated/61Deprecated package to not break existing code that relies on it. Another example, #<span>openGIFInWindow:/#fromStream: are not understood by BetterAnimatedImageMorph class.</span></span></span></li></ul></div></div></blockquote><div><br></div><div>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)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-3387757843769282171divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr"><ul style="margin-bottom:0px;margin-top:0px"><li><span>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.</span></li></ul></div></div></blockquote><div><br></div><div>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. </div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div id="gmail-m_-3387757843769282171divtagdefaultwrapper" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif,EmojiFont,"Apple Color Emoji","Segoe UI Emoji",NotoColorEmoji,"Segoe UI Symbol","Android Emoji",EmojiSymbols" dir="ltr">
PS: Have you or someone else already tried to optimize the new GIFReadWriter for performance? I am having a 36 MB large
<a href="https://github.com/LinqLover/TelegramSmalltalkBot/blob/master/img/screencast.gif" target="_blank">
GIF</a> 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.</div></div></blockquote><div><br></div><div>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.</div><div>  </div><div>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. <br></div><div>  </div><div>That said, are there other packages available for profiling etc, or is MessageTally class >> spyOn: the bread and butter for that kind of thing?</div><div>  </div><div>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.</div></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Eric</div></div></div></div>