Re: An alternative to gdk-pixbuf

On Thu, 2018-09-06 at 11:39 +0100, Emmanuele Bassi via gtk-devel-list
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
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
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.

Gegl is great for image editing. But not as much for simple

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

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
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
- 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

[1]: I recently did this to add webp comics support to the evince

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]