If emacs used only GTK to draw things to the screen, then indeed there
would be no need for those conversions, as GTK would handle them.
Exactly.
That's great. The way towards Wayland also. Sounds like a LOT of work, though.
I've been working in an alternative to this patch and the one that fixes the cairo fringe. My goal is to provide a gtk+cairo solution that listen to gtk scale changes and scales everything (including fonts) accordingly. This would enable an adaptive multi-monitor multi-dpi emacs using the old scale-up-gtk then scale-down-xrandr trick, a nice implementation of which, including GUI and everything, is going to be part of the next Ubuntu LTS with high probability.
I'm having a really hard time making the font engine abandon it's idea of pixel-sized fonts that is very entrenched in its caching mechanism once everything was first rendered at some initial dpi. The only way I found to circumvent this is to report a fixed 96dpi resolution and then scale all cairo rendering (fonts, images, bitmaps) using the platform scaling factor. This mostly works but I'm still unable to get rid of all previously opened fonts, even after clearing all ftcrfont caches, so I get a mix of different sized fonts. It will probably take me some time to figure out what's happening.
So I'm closing this issue and will open a new one once I have an integral cairo+gtk solution working in a way that mostly resembles the nsterm backend.
Best regards
--
Carlos