Re: An alternative to gdk-pixbuf

[Magnus Bergman <magnus bergman snisurset net>]

On Tue, 11 Sep 2018 13:22:17 +0200
Bastien Nocera <hadess hadess net> wrote:

> On Tue, 2018-09-11 at 07:40 +0100, John Cupitt via gtk-devel-list
> wrote:
> > On Tue, 11 Sep 2018 at 03:11, Magnus Bergman
> > <magnus bergman snisurset net> wrote:  
> > > On Tue, 11 Sep 2018 00:07:27 +0200
> > > Bastien Nocera <hadess hadess net> wrote:  
> > > > No, it really isn't:
> > > >   
> https://www.cvedetails.com/vulnerability-list/vendor_id-1749/Imagemagick.html
> > > > We want to have less CVEs, not more.  
> > >
> > > I see what you mean. A few of them (although none of the more
> > > serious
> > > ones) were even related to the GIF loader specifically. But the
> > > sheer
> > > volume kind of speaks for itself otherwise. :(  
> >
> > IM joined Google's OSS-Fuzz programme last year:
> >
> > https://github.com/google/oss-fuzz
> >
> > The huge surge in CVEs was caused by that --- they've been fixing
> > one or two a day ever since. Once they are through this very painful
> > process, IM ought to be rather safe.
> >
> > I do agree though that it's a large and complex thing to use for
> > such a (relatively) simple task.  
>
> I maintained ImageMagick in RHEL a long time ago, it was already that
> way though security issues cropped up a bit less often than every day
> (!). I don't see any reason for us to want to us it.

Understandable. Anyway, I made a third GIF loader based on libnsgif
and released it. This one also handles all images in the test suit and
displays 1_partyanimsm2.gif nicely too (before I even found something
that could view it I wasn't sure if it was supposed to show garbage or
not). Since libnsgif is very straight forward to use I guess you prefer
to write your own loader instead of having abydos in the middle. If
you don't already know the API of libnsgif (it lacks documentation) it
is probably very easy to get started by porting the abydos plugin to
gdk-pixbuf. And here are some tips about things you might want to
implement differently:

The pixel format libnsgif uses happens to be the same as for gdk-pixbuf
(both for big and little endian). This means that the bitmap_create
callback can be used to create a GdkPixbuf and bítmap_get_buffer to
return the pixels of the GdkPixbuf, so libnsgif can draw directly into
it. However this assumes that the rowstride equals the width (which I
guess is a valid assumption for RGBA). It would be easy just returning
a copy of this GdkPixbuf then requested and use gif_decode_frame() to
change the frame then needed (obviously using locking since several
independent GdkPixbufAnimationIter could theoretically be used at the
same time even if it's a highly unlikely use case). This will possibly
make it even simpler and more readable than the approach I took with
the abydos loader. The reason I chose to decode all frames directly
upon load and then throw away the gif_animation was manly because the
conversion of abydos doesn't require the pixels to be copied. Also note
that progressive loading is supported by libnsgif, but instead of just
feeding it the new bytes, it needs a buffer containing all the previous
bytes as well. And you probably want to add support for (netscape
style) looping, which is something abydos doesn't support yet.