Re: An alternative to gdk-pixbuf

[Emmanuele Bassi <ebassi gmail com>]

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.

 

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

Not really; icons—especially ones that are identified via icon theme names—are a very narrow subset of "all the possible images and formats in human history".

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.

 

It doesn't do animation

Animated formats are a dying breed, and they have all but killed by VP9 and new, web-friendly video formats. Social platforms will take a GIF and turn it into a video transparently.

Additionally, GTK 4.x already has new API to render videos and other frame-based media sources through GStreamer.

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

That's up to the toolkit, as it's going to be the one deciding how to render the rest of the UI. There's no way for you to know, from the outside, how to efficiently render anything.

That's why it's much, much better to get a memory buffer with the contents of the image, and let the toolkit pass it to the GPU.

Vector formats are different, but that's why we have API like Cairo or Skia; I'm also waiting for web browsers to implement SVG rendering on the GPU where possible, with the help of new primitives from the GL/Vulkan implementation.

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

Ciao,

 Emmanuele.

--

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