Category: Fellowship

The GNOME Foundation is supporting contributors with its fellowship program. You can help expand the fellowship program with a donation.

The previous month concluded with releasing the beta versions for GNOME 51. So this month, it was about time to get the bugs fixed in the beta releases.

Tales of a Dicey API

To give you a peek into my work, I’ll walk you through debugging an annoying issue. This problem had been floating around for a while during the GNOME 51 cycle. GNOME Shell was failing to load some of the app icons in the app grid. While I was pretty sure that the issue wasn’t the fault of libglycin, I finally decided to track down the problem myself. Luckily, running a nested GNOME Shell is pretty simple and well documented. Tracking down the key symptom was a question of systematic search. As it turned out, glycin was blocked as soon as it reached any asynchronous Gio.File operation. But why? Dumping the tracebacks of all the GNOME Shell threads via gdb gave an insight into Shell’s state: There were a lot of threads named pool-<n>, blocked on waiting for Gly.Loader.load to make progress. That’s exactly how Gio.Task names threads in its thread pool.

Hence, we had two important observations: Operations like Gio.File.open_async were not making progress. At the same time, there were a lot of threads on the Gio.Task thread pool that were stuck on calling Gly.Loader.load. Knowing more about GIO’s internals, this would immediately reveal the issue. Knowledge that I was lacking. I read GIO’s async documentation yet again, but I still couldn’t make sense of this behavior. Luckily, Sergey Bugaev and Sebastian Dröge immediately connected the dots: GIO’s async operations on Gio.File rely on the Gio.Task thread pool internally. However, the creation of new threads in the pool is heavily throttled. With that context, the issue became clear: GNOME Shell was trying to spawn as many threads as there are app icons via Gio.Task.run_in_thread, each thread waiting for a Gly.Loader.load call to return. For Gly.Loader.load to load the app icon from the disk, Gio.File.open_async would need a thread on the thread pool. However, as soon as the throttling allows the creation of a new thread, GNOME Shell would spawn yet another thread to load another app icon.

As far as I know, this interaction of the user-facing APIs like Gio.Task.run_in_thread and GIO’s async internals is not documented anywhere. Generally, just spawning as many threads on the task pool as possible is quite a fragile design decision, as it is hard to reason about and ensure that this is not starving other important operations from obtaining a thread on the thread pool. These are issues well known to some people. One suggestion has been to just remove or reduce the throttling of thread creation. However, designs like the one in GNOME Shell show that API consumers rely on the throttling, since otherwise, Shell might spawn in the order of hundreds of threads in one moment. There are also unsolved issues with memory management that go back to 2018. I think it is time to act on the conclusion that many people already had: This GIO feature is fundamentally broken. I have now proposed to deprecate the API.

After understanding the issue, something else clicked for me: I had seen issues with Nautilus mysteriously being stuck on file copy operations for a while. Now, that made sense: Nautilus was blocking the Gio.Task thread pool with loading thumbnails, running into the same issue as Shell. But not only were thumbnails not loaded, other Gio.File operations were blocked as well. While I previously thought about just fixing GNOME Shell by properly using libglycin’s async API directly, it now became obvious that far too many apps might rely on being able to occupy the complete thread pool. Hence, libglycin’s sync API would need a workaround for at least this cycle until the issues could be addressed properly in the API users. Glycin now tracks the information of something being a sync API call and then uses GLib’s sync APIs internally.

Hopefully, we can port our apps to using proper async APIs for GNOME 52.

Other Work

Of course, I worked on lots of other things this month. Here is a short overview.

Glycin

• • Fixed broken colors after editing a rare kind of JPEG where colors are encoded as RGB instead of YCbCr.
  • Allowed editing JPEGs with dimensions larger than 16,384 × 16,384 pixels. This was previously prevented due to accidentally using zune-jpeg’s default options in editing.
  • Added some missing API documentation.
  • Worked around a memory leak in gtk-rs’s gio::spawn_blocking. This issue has been fixed in a new gtk-rs release by now.
  • Finally merged the pixel density support in gdk-pixbuf’s libglycin shim.

Loupe

• • Fixed some issues with the new dialogs asking to save unsaved changes when editing.
  • Fixed a race condition when showing an edited image. This is still not completely behaving as intended and will need some more work during the GNOME 52 cycle.

Other Projects

• • Cleaned up the code for cargo-lock-analyzer. Also added an overview of Rust dependencies with security issues in our stack. This is still pretty experimental, and I’m thinking about how we can integrate this into a larger security tracking system for our dependencies.
  • Updated some apps to resolve open security issues. However, none of them seem to have any practical relevance for us.
  • Brought the proposal for an RFC process to the next step. It is now a merge request, following the RFC logic. Incorporated some of the feedback.

Outlook

This month was a bit slower than the previous month, since I worked some additional hours in July. Due to my disabilities, my contract is about the equivalent of a 1/3-position. I am very thankful that the Foundation has accommodated that. So my progress might be a bit slower in general.

For GNOME 52, there are exciting things ahead: Inkscape has ported their handling of raster graphics to libglycin. However, they still need CMYK and PNG interlacing support in libglycin to land the changes. This is something I will work on soon. For Loupe, there is an open merge request for saving images in different formats, which I’m looking forward to being completed.

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.

On July 1st, the very first round of GNOME Fellowships started. This program finances contributors within the GNOME project through your donations. We, the fellows, will be giving you monthly updates about our work. This is the very first update from me.

Short Introduction

Hey, I’m Sophie. I have been working with GNOME technology for eight years. While I’m a physicist by trade, I have been programming for more than 20 years. You might have used apps like Pika Backup, Image Viewer, or Key Rack, which I developed, or used websites like apps.gnome.org or welcome.gnome.org that I created.

Among my goals for this fellowship are to get the image library glycin into the state that we can deprecate its predecessor gdk-pixbuf, establish new governance structures like an RFC process in the GNOME project, and explore better integration of Rust in the GNOME ecosystem.

Glycin

Glycin has already seen relatively fast adoption. One of the major reasons is that media processing code written in C is a major attack surface. In this year alone, five security issues have been reportedagainst the gdk-pixbuf project. In the future, glycin-exclusive features like higher color-depth support, proper color space management, and HDR support will become even more relevant.

Gdk-pixbuf has switched to using glycin as the default backend on Linux for a while. This way, the attack surface is already largely reduced. However, not all distributions have adopted the option yet, and on other platforms like Windows and macOS libglycin hasn’t been available to begin with.

One feature missing from glycin that is supported by gdk-pixbuf has been support for reading and writing pixel densities from images. This feature is now available for JPEG, PNG, and TIFF images. I have also created a merge request to support this feature in gdk-pixbuf via the glycin backend.

I already added basic support for macOS and Windows, as well as other operating systems, to glycin before the beginning of the fellowship. To address a few remaining build issues on Windows and macOS for libglycin, I explored fixing them by switching the complete build process from cargo to meson. However, it turns out that the meson main branch is still lacking features to make this work. Instead, I landed a patch by Felix to work around the issues. There are still some issues remaining on Windows with the GCC instead of the MSVC compiler. If someone has experience with that, fixes are very welcome.

Here is a quick list of all the smaller changes that have landed in glycin over the last month:

• • OpenEXR images that use half-precision floats now use the same memory format in glycin, saving half of the memory compared to the previously used single-precision floats.
  • Support for the Radiance HDR format has been added.
  • The lcms2 C-library has been dropped in favor of moxcms, which is written in safe Rust and improves the performance for images with ICC profiles noticeably.
  • Internally, there is now a mechanism for a loader to report if ICC profiles or CICP (HDR instructions) should be preferred, since this differs between image formats.
  • There is now an option to disable the glycin sandbox by setting the environment variable GLYCIN_DISABLE_SANDBOX=i-know-the-risks. There is now also a test_disable_sandbox meson option to disable the use of sandboxes when running tests for build servers that don’t support sandboxing.
  • Glycin’s seccomp filter now uses a blocklist instead of an allowlist. This simplifies the feature a lot and should be sufficient since the seccomp filters are only a second line of defense behind guards like namespaces. It should also fix an issue with 32-bit apps, like Steam, calling 64-bit loaders.
  • When creating new images, glycin now supports automatically converting the provided texture memory format to a format supported by the targeted image format. This feature can be controlled via Creator::set_transform_memory_format. As a result, glycin is now aware of the supported memory formats for all image formats. This information is now available via ImageEditorConfig::creator_memory_formats.
  • Metadata support has been extended by also loading XMP data for GIF, TIFF, and WebP images.
  • On request of the Inkscape project, a new API to disable the automatic conversion of textures to sRGB if an ICC profile is present has been added, along with a new API to fetch ICC profiles. This gives apps optional manual control over color management.

Image Viewer (Loupe)

The Image Viewer is showing some of the new information that is available via the new glycin features.

If pixel density metadata is available, it is shown in DPI, as well as the calculated physical size of the image. One example where this is particularly useful is scanned photos where the information is automatically added.

The used color profile, either ICC profile or CICP data, will also be shown.

RFC Proposal Draft

I have posted my first draft of a proposal for an RFC process within the GNOME project. Previously the document went through several iterations with the goal of striking a balance between making the decision process robust and avoiding stalls, while also not making it too complicated and bureaucratic. The initial discussion about the proposal is now taking place. For more information on why we are working towards better governance structures, I suggest reading Emmanuele’s original post.

Support the GNOME Project

The GNOME Fellowships are funded by our community. If you would like to help the GNOME project to stay sustainable, please consider donating.