Megapixels 2.0: Small fixes and GTK breakage

Looking back it seems like making an alpha release of Megapixels 2.0 was a great choice. The various components that make up Megapixels have been through the packaging steps at Mobian for example which brought some light to issues that would improve the packaging. A lot more eyes have hit the code in this release than the random stuff thrown to git and I'm really happy I've received a lot of improvements from a bunch of developers.

When I started working on Megapixels it was my first C codebase, when I started working on libmegapixels/libdng those were the first times figuring out how do do C libraries. In the years I've been working on this codebase I've leared a whole lot, mostly around cleaner code and seeing merge requests that fix up minor issues in the code are a great reference for figuring out what the idiomatic way is of writing specific pieces of code.

Of course quite a few of these are minor memory safety violations and there has been a few un-free()'d resources around within Megapixels, but in the end running free on a few bytes before quitting the app or letting Linux release that memory doesn't make that much of a difference, most of the effort has been going through making sure the main image processing loop doesn't leak memory anywhere. If that part leaks memory then it will starts adding up really fast :)

GTK throwing a wrench into the development process

Of course Linux development can't ever run smoothly... there's always something new and exciting to break everything.

In the case of Megapixels it has been the NGL backend for GTK4. The 4.17 release made in Februari dropped the GL backend in favor of the NGL and Vulkan renderers. Which is great if you're on the latest and greatest Macbooks.

The issue is that GTK now also dropped for GLES 2.0 which means that a lot of older devices are no longer GPU accelerated in GTK4. For Megapixels it's an even bigger issue since the debayering depends on GPU acceleration so it won't run at all if GTK4 doesn't have an OpenGL context anymore.

This hardware doesn't even have to be terribly old. For example here's some of the hardware supported by Megapixels 2.0:

What they all have in common is that they don't really support the latest and greatest OpenGL versions. It's not very easy to get any hard docs on what OpenGL requirements GTK has now, but it seems like it's at least OpenGL 3.3 and there's still references to OpenGL ES 3.0 in the codebase. Which means that for the devices I've been targetting for Megapixels the support simply isn't there anymore.

So far there's been a workaround for this by putting Megapixels in a flatpak with a runtime that doesn't have the latest version of GTK4 in it. This is obviously not a long term solution but at least there's some workaround for now. Many thanks to Andrey Skvortsov for creating a flatpak package for Megapixels.

There's a build available now on my flatpak repository, you should be able to get your favorite graphical packagemanager frontend to install it with this link: https://flatpak.brixit.nl/megapixels2.flatpakref

The future

I'm not entirely sure what a good solution for this mess is. My current feeling is that it's best to not rely on GTK4 anymore because even if somehow a workaround is figured out to make this work, there's always the next GTK issue coming up.

Switching to another framework also isn't great, especially since Megapixels just has been through rewrite hell already, it'd be 2026 before we'd have a working camera app again. In theory it should be slightly easier now to make megapixels-qt now with libmegapixels but that only abstracts the device usage, the main magic of Megapixels is the threading mess and OpenGL debayer code that gives it the realtime performance for photography and that would have to be recreated on another platform.

Maybe someone has a great idea or a solution for this, I'd love to hear it.