But it does seem sad that for years now this problem has been known, and no-one other than @Carmelo_DrRaw seems to have come up with any solution, and that solution is a not an actual solution but a workaround.
This bug report says “something” was fixed (the bug was closed as fixed) , I wonder what that “something” was, as it apparently didn’t actually fix the real problem: https://bugzilla.gnome.org/show_bug.cgi?id=681784
From skimming through the bug report, it appears that Gtk/Cairo is pretty ignorant of Color Management, and on dealing with OS X has stumbled into problems. My conclusion is that there are three ways this could be dealt with in increasing level of difficulty:
-
Make Gtk/Cairo render everything in native device space, which (I gather) would make it behave the same as the MSWindows and X back ends. You need to use the null transform trick to do this with recent OS X releases. Down side is that all the UI elements will be garish on wide gamut displays.
-
Gtk/Cairo needs to distinguish between UI elements it is rendering and values that the application is handling. For the former it could use sRGB as the tag, and for the latter the application is expected to do the color management and Gtk/Cairo use the null transform tag with OS X for those elements.
-
Gtk/Cairo support color managed back ends properly, by supplying the API’s to let the application tag all the color elements. That would mean implementing color management for the X back end, and using the MS CMM machinery to manage color for the MSWindows back end. The OS X back end would be pretty easy. Wide gamut displays are then fully supported.
(1) Would seem the most trivial to implement, but it could be that it’s not easy because Gtk/Cairo is hiding what display various things are on, and it is necessary to know which display is which when the application is doing color management or the null transform trick is used. This would be an issue if OS X allows rendering elements across multiple displays with a single call, and Gtk/Cairo is relying on such behavior rather than breaking up the rendering into separate calls for each display. (I wouldn’t have thought that was the case though, since in general you can’t rely on a back end supporting such a thing.)
[ Note that Wayland is in the “extremely difficult” basket to implement Color Management on. It basically can’t be done without introducing a color management extension, because of a fundamental blunder in the underlying assumptions made in Waylands design. (Lack of awareness of Color Management amongst graphics developers bites big-time!) And the Wayland developers seem to be actively hostile to introducing a Color Management extension. ]