Hey all,

Sorry I'm a little out of my depth here. Did I screw up the timestamps
somehow? What's the best way to update them? Also my understanding is that
if I push to Trunk, I will have to do a different push for each package
that has changed, is that correct?

On Fri, Dec 10, 2021 at 8:19 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Maybe change the missing stamps to "Eric Gade"? :-) I know that he did not
> touch all the code but most of it?
>
> Best,
> Marcel
>
> Am 10.12.2021 13:49:53 schrieb Levente Uzonyi <leves at caesar.elte.hu>:
> Hi Eric,
>
> I think the code can be optimized further and I think it's possible to
> make it faster than the current Trunk version (which is a mess btw).
> But I wouldn't bother with that at this point. I suggest upgrading the
> changeset to have proper method stamps instead of "no timeStamp · unknown
> author", converting it into mcz files, and pushing it into the Trunk.
> That way others can review the code more easily and will have a
> chance to contribute as well.
>
>
> Levente
>
> On Thu, 9 Dec 2021, Eric Gade wrote:
>
> > Hi all,
> >
> > I'm attaching an updated changeset that should by itself have everything
> you need. It includes a couple of changes that should help with
> performance:
> > 1) The use of ByteArrays instead of generic OrderedCollections or Arrays
> where we are definitively dealing with byte values;
> > 2) Removal of unnecessary buffering of data blocks. The GIF standard --
> which is from 1989 -- described data blocks that are max 255 bytes large. I
> had been taking the standard as literally as possible, so was essentially
> > refreshing the buffer every 255 bytes. With this changeset we are now
> buffering all data bytes ahead of time into one single ByteArray, which
> shouldn't be an issue for each image frame.
> >
> > I have noticed a GIF reading speed improvement of >50% due to these
> changes. However, larger GIFs can still take quite a bit of time.
> >
> > Additionally, I have removed and/or deprecated methods that are no
> longer being used.
> >
> > Does anyone have additional thoughts about the tests and how Color black
> does not equal the pixel value of a Form that was filled in with Color
> black?
> > --
> > Eric
> >
> >
>
>
>

-- 
Eric
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20211210/4890d4b0/attachment.html>