bug#37770: [PATCH] Expose scale factor through the redisplay interface

[Carlos Pita <carlosjosepita@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

>
>
> 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.

>
> <https://github.com/masm11/emacs> is attempting to implement a 'pure'
> GTK backend. I have no idea how close it is to being ready to merge.
>

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



>

[-- Attachment #2: Type: text/html, Size: 2680 bytes --]