Move away from GdkPixbuf

There has been interest to move away from GdkPixbuf for a while. The main reason is the notorious security issues in image decoders. That's also the reason why Loupe wasn't based on GdkPixbuf. After repeated discussion about abandoning GdkPixbuf, there have been some experimentation with replacing it by glycin.

There hasn't been a decision yet.

Advantages of glycin

• Image decoders are sandboxed via Linux namespaces (bwrap) and a seccomp allow list
• Code outside of the sandbox is mostly memory safe (Rust). The most important exception is lcms2.
• Most decoders are written in safe Rust (image-rs)
• Some image-rs loaders are much faster. For example, glycin seems to be 7x faster for some large JPEGs.
• Supports formats that GdkPixbuf dropped (?) like .ico and can be extended with more peace of mind
• Centralized and more complete handling of metadata and color management
• Supports extraction of metadata like XMP and Exif
• Supports more than 8bit colors and CICP
• Can directly produce GdkTextures, without detour through intermediate objects

Drawback of glycin

• Sandboxing makes the overall structure a bit more complex
• Sandboxing brings additional overhead: Spawning the sandbox needs an extra 4ms. With repeated calls of bwrap this can increase to 20ms. Reason is unclear. For consumers that know that they will load a lot of small images, having a loader pool could be a good optimization. The pool feature will not happen overnight.
• The currently used TIFF loader does not cover a bunch of formats glycin#49 glycin#53 glycin#78 glycin#86
• No plans to support incremental loading
• Currently does not work on Windows when used directly

Missing glycin features

These are important to make an initial transition possible

• Support taking bytes instead of GFile glycin#98
• Get images in one specific memory layout glycin!133
  • Makes it much simpler to write the GdkPixbuf plugin
• Saving images
  • Makes it simpler to write a glycin based thumbnailer
• Move from zbus to glib for D-Bus to reduce binary sice and #dependencies
• Support BSD
  • Features like seccomp and sealing memfds have to be disabled. That might be it.
• Support MacOS
  • No clue

Other features that GdkPixbuf provides, but unclear if needed in this form in glycin

• gdk_pixbuf_add_alpha
  • Sounds very specific
• gdk_pixbuf_composite
  • What is that? Does anyone need it?
• gdk_pixbuf_composite_color
  • Seems to be about checkboard patterns, not sure if we want them today
• gdk_pixbuf_saturate_and_pixelate
  • Not sure if we want pixelate anywhere
• gdk_pixbuf_scale
  • Can be done via GTK Snapshot

Steps to replace GdkPixbuf

There is the idea to make GdkPixbuf a shim for glycin by having a plugin that forwards all requests to glycin

• Have a glycin GdkPixbuf plugin
  • Proof of concept implementation gdk-pixbuf!178

A GdkPixbuf thumbnailer with glycin shim will probably not work since a sandbox cannot be spawned inside a sandbox.

• Have a glycin thumbnailer
  • According to @matthiasc disabling the glycin sandbox is enough. We just need to write an directly glycin based thumbnailer.
  • Currently gdk-pixbuf!178 detects if GdkPixbuf is running in a thumbnailer.

Further steps that would be needed

• Accept glycin into Core and move it to GNOME/ gnome-build-meta#845 (closed)
• Make glycin loaders part of the runtime
  • If it's not part of the runtime and GdkPixbuf is a shim, apps will fail to load images.

GTK can't drop its GdkPixbuf dependency until 5.0, since it is exposed in the API. A goal of this initiative should be to port applications away from gdk_texture_new_for_pixbuf, gtk_image_new_from_pixbuf and gtk_picture_new_for_pixbuf.

• Deprecate remaining pixbuf apis in GTK: gtk!8061