Re: An alternative to gdk-pixbuf

[Emmanuele Bassi <ebassi gmail com>]

Hi;

On Tue, 4 Sep 2018 at 23:19, Magnus Bergman <magnus bergman snisurset net> wrote:

Over the years it has been discussed from time to time to replace
gdk-pixbuf with something else[1][2]. Something was even in the making
(I guess over ten years ago) but it never replaced gdk-pixbuf
apparently. Now I don't even remember what it was called. And something
else called pig was proposed more recently.

One major reason to replace gdk-pixbuf has been the long term goal to
phase out GDK in favour of cairo. And some people (including me) has
been displeased with the gdk-pixbuf API for more subtle reasons. It has
also been brough up that it lacks some features (which I guess are hard
to implement as an afterthought). I finally took some time to design an
image loading library on top of cairo called abydos, which at least
suits my needs. And also some needs mentioned in this list over the
years. First I thought it could suit the needs of GTK+ as well. But I
just learned that even cairo is now considered "legacy technology" by
the GTK+ developers[3], so I guess cairo is also being phased out now.
But in favour of what?

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.

Cairo is still used as a fallback mechanism — both when running on platforms without support for OpenGL or Vulkan, and in the interim period while the GL/Vulkan rendering pipelines inside GTK don't support a CSS feature. Additionally, you may still use Cairo for 2D high quality rendering, for printing and for custom drawing.

Internally, GTK only cares about GdkPixbuf in as much as it provides us with a way to load graphic assets like icons, which are typically in a very limited amount of formats. As far as we're concerned, image data coming from GdkPixbuf and Cairo gets loaded into memory buffers that get submitted to the GPU almost immediately, and all transformations and rendering happen using shaders, on the GPU.

Anything bigger than an icon should probably be loaded and displayed through Gegl, the same library used by the GIMP; this is especially true if you're planning to process the image using filters. Images, these days, are pretty big buffers — and so are displays; using a simple linear buffer like GdkPixbuf's does not scale.

From the perspective of a consumer of GdkPixbuf, the only thing that an image loading library should do is, pretty literally, load images. No scaling, no compositing, no rendering. Saving to a file may be interesting — but that opens the whole transcoding can of worms, so maybe it should just be a debugging feature. Ideally, I/O operations should happen in a separate thread, and possible use multi-threading to chunk out the work on multiple cores; it definitely needs to integrate with GIO, as it's a modern API that well maps to GUIs.

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.

Ciao,

 Emmanuele.

--

https://www.bassi.io
[@] ebassi [@gmail.com]