[FR] A solution to better image rendering and HDR display output without GTK migration

[Auxx]

Is your feature request related to a problem? Please describe.
One thing I heard why HDR display is impossible at the moment is due to GTK3 being used. But there is a simple solution which doesn't require migration and is adopted by other applications like Lightroom and Resolve. That will also improve rendering accuracy in general.

Describe the solution you'd like
The solution is to use native rendering surfaces for each OS instead of GTK/Cairo. This is how it works in Adobe and Black Magic software.

As far as I understood the code (haven't written any C/C++ in over a decade, so I'm very rusty, sorry), the rendering canvas is already a stand alone component which uses Cairo. It can be replaced with an OS native surface (like DX11 for Windows, Metal or whatever for MacOS, etc) and render the image using all available tools, like 10 bit output, wide gamut support, HDR support, etc. This code will also be beneficial after GTK4 migration as I don't believe GTK4 supports any advanced colour management features from all OSes.

The workflow I see in my head is as follows:

1. Detect image buffer requirements for current OS (8/10 bit, colour gamut, HDR support).
2. Update renderer into buffer to use the expected data format.
3. Replace Cairo surface with a native surface.
4. Draw image buffer into native surface.

Cairo can still be used as a fallback for unsupported systems, like older Windows versions without ACM and HDR support or Linux distros running outdated stuff.

I can try and provide some assistance for Windows side of things, but since I haven't touched C/C++ in a long while I will definitely need some guidance navigating the code base. A good code example for Windows is dogegen (pattern generator for colour calibration).

[kmilos]

x-ref #17710 and #18078

[ralfbrown]

The solution is to use native rendering surfaces for each OS instead of GTK/Cairo. This is how it works in Adobe and Black Magic software.

Darktable has the equivalent of two (three in a good month) full-time programmers, with barely enough resources for bugfixes on two of the three officially-supported operating systems.... So there's a real reason behind darktable avoiding platform-specific code.

The best-case outcome I see for this proposal is that Linux/Wayland gets native surfaces while Linux/X11, Windows, and MacOS stay on Cairo.

[Auxx]

@ralfbrown that's understandable, but if DT developers agree that rendering surfaces independent of GTK is a good way forward and are willing to lay some groundwork to support such workflow, then I'd be happy to do Windows DX11 surface and support it. And, obviously, there's no point doing that if DT devs do not wish to take this route at all, as I don't think I can refactor existing code good enough to be accepted.

If idea is good in general and is accepted, then I can see the following tasks:

• Groundwork: add platform dependent detection of output format (defaults to sRGB 8 bit, same code for all platforms at first, just in different files). My guess would be that the following parameters are needed: colour resolution in bits, RGB primaries coordinates in xy, white point in xy, dynamic range in stops or contrast ratio (10 stops for SDR, 14 or 16 for HDR), and gamma curve (2.2 by default for SDR, PQ for HDR later on).
• Add correct detection for supported platforms (Linux/Wayland can be done by DT team, I can do Windows - DX11 capabilities for Win11, sRGB 8/10 bit otherwise).
• Groundwork: refactor current renderer to use detected output format and prepare a buffer in a correct format.
• Groundwork: create separate platform dependent rendering surfaces, use Cairo in all of them initially.
• DT team can start implementing Linux/Wayland, I can start Win11/DX11.

Someone later might jump in and add MacOS surface.

In any case such work will future proof the project. If native surfaces/APIs change or new OS is added, then there will be no dependency on GTK or any other possible UI toolkit and everything can be updated independently. In the worst case scenario there will always be a Cairo fallback, so there will always be a way to use Darktable in a predictable manner no matter how software and hardware evolves.

I understand that even groundwork tasks will take a lot of effort, but I believe it will be worth it in the long term. I also think that groundwork can happen in the background when people have free time without affecting existing functionality. For example, format detection can just set some variables somewhere in memory or whatever and the rest of application can just ignore them until everything is ready. Then some time later work on renderer can start, and since the default detected format will be the same as what it is right now, renderer changes should have no effect on end users. And then the first surface will be Cairo, so once implemented - again, no visible changes to the users.