On Wed, 5 Sep 2018 at 19:25, Magnus Bergman <magnus.berg...@snisurset.net>

> On Wed, 5 Sep 2018 17:28:22 +0100
> Emmanuele Bassi <eba...@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

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


[@] ebassi [@gmail.com]
gtk-devel-list mailing list

Reply via email to