Re: An alternative to gdk-pixbuf

[Bastien Nocera <hadess hadess net>]

On Thu, 2018-09-06 at 11:39 +0100, Emmanuele Bassi via gtk-devel-list
wrote:
> On Wed, 5 Sep 2018 at 19:25, Magnus Bergman <
> magnus bergman snisurset net> wrote:
> > On Wed, 5 Sep 2018 17:28:22 +0100
> > Emmanuele Bassi <ebassi gmail com> wrote:
> >
> > > We're phasing out Cairo in favour of the CSS rendering model,
> > > implemented on top of OpenGL and Vulkan, as it's the API that
> > most
> > > closely matches the requirements of GTK.
> >
> > I'm not sure I quite understand what you are saying. What does this
> > mean for image loading if terms of actual implementation? What
> > would
> > ideally happen then GTK+ needs to load an image (because the
> > application called gtk_image_new_from_file() for example)?
>
> We're still using GdkPixbuf, and for the 4.0 API series we still have
> GdkPixbuf types exposed in the GTK API.
>
> For future API series (5.x, 6.x, …) we may revisit this, with the
> option of moving icon loading into GTK itself.

This uncertainty is the reason why I didn't work on moving the
thumbnailing code somewhere else, as it's bound to be made irrelevant
sooner rather than later.

<snip>
> > Gegl is great for image editing. But not as much for simple
> > viewing.
>
> This is debatable. If I'm viewing a 4000x4000 RGB image on a hidpi
> display I'm already pushing gdk-pixbuf and cairo to their limits
> because of the scaling factor applied to the window — not only the
> buffer gets loaded uncompressed to allow for zooming, but the image
> viewer needs to render a CPU-scaled down copy of the image.
>
> Sure, for viewing a 500x400px image macro for a meme we're fine; but
> we're fine with gdk-pixbuf as well, so there's really no need to
> change to a different image loading library.

I concur, 4000x4000 would likely OOM your machine, and it's not really
fixable:
https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/30

Viewers should use GEGL, and GEGL should be taught about more formats.
That still leaves many GIF files unhandled though, and I'm not sure
we'd want apps writing their own GIF loader, seeing how complicated
that is.


> In the near future, I'll very likely deprecate most of
> > GdkPixbuf's
> > > API, except for the I/O operations; I'd also be happy to seal off
> > > most of its internals, within the ABI stability promise, to avoid
> > > leakage of internal state.
> >
> > Will the loader plugin API go away, you think?
>
> No API will ever go away: there are no plans for a gdk-pixbuf-3.0.
> The deprecations would mostly apply to API that is either long since
> been replaced by Cairo (scale/composite), or that is weirdly ad hoc,
> like saturate_and_pixelate(). Ideally, I'd like to deprecate the
> option to build gdk-pixbuf without depending on GIO to do MIME type
> sniffing, as GIO has been fixed to work on Windows and macOS, and it
> is a required dependency anyway.

That's probably fine, though the current code in the stack is dumb as
rocks, and will try to thumbnail a JPG file with the PNG decoder if the
suffix is incorrect. The error message is also obnoxious, so that'll
need fixing before removing the content type sniffing.

>  The animation API is pretty much a garbage fire, so it may go on the
> chopping block as well. Of course, deprecated API will keep working
> as well—or as badly—as it works today, so people can still use it.
> Moving pixbuf loaders to separate processes, and wrap them in
> sandboxes, would be a fairly good thing to do; it need to be decided
> at run time, though, because there are many users of GdkPixbuf that
> already run in a sandbox, which prevents creating smaller sandboxes
> inside it.

That'd be best left to an API that can do that natively, with the API
being thought out ahead of time.

In the short term, my wishlist/TODO list would be:
- somebody writes a GIF loader that is readable, and passes the test
suite.
- we disable every loader by default except the ones that the core
desktop needs
- image viewers that rely on gdk-pixbuf ship their additional loaders
in the app's Flatpak[1].

That would already reduce the attack surface for gdk-pixbuf.

On a sidenote, I also use gdk-pixbuf as a pixel-perfect drawing API for
thumbnailers:
https://gitlab.gnome.org/Archive/gnome-nds-thumbnailer/blob/master/gnome-nds-thumbnailer.c#L72

[1]: I recently did this to add webp comics support to the evince
Flatpak:
https://gitlab.gnome.org/GNOME/evince/merge_requests/50