Re: An alternative to gdk-pixbuf

On Wed, 5 Sep 2018 17:28:22 +0100
Emmanuele Bassi <ebassi gmail com> wrote:


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.

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

Will GTK+ have a limited set of hard coded loaders which can render
images directly using both OpenGL and Vulcan? So one custom SVG loader
for OpenGL and one custom SVG loader for Vulcan. And likewise for every
other supported image format (I guess at least PNG, JPEG, GIF, WEBP and
Windows Icon).

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.

But then it comes to printing and custom drawing I'm on my own then it
comes to loading the images? Which is okey of course since gdk-pixbuf
is kind of a separate library already. But isn't it a good thing to
share common image loading code?

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.

I'm not convinced that you should need to use one image loader for
loading small images and another for loading full scale images (such as
ordinary photos). Then it comes to really large images (many times the
RAM size) I can agree that something else might be needed.

Gegl is great for image editing. But not as much for simple viewing. It
doesn't do animation and doesn't support vector graphics (apart from
converting them into pixmaps). Also it only loads images from the
file system and is a bit bulky to use. It simply doesn't fit the needs
for a simple image viewer.

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.

Yes, I very much agree with this. Except I think it has to do rendering
of some sort. If an image contains a triangle, it has to be converted to
a function call that renders it (using OpenGL/Vulcan/cairo) somehow.
Just handing over a set of geometrical objects hasn't taken you very far
from the original coded data, basically just converted it into another
vector data format. Spreading the work over multiple threads I mostly
consider an implementation detail. Or do you think it needs to be
considered then designing an API for image loading? And if you have
looked at the API of abydos, do you think it requires some changes to
fit the needs you mention?

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?

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