[debbugs-tracker] bug#37770: closed ([PATCH] Expose scale factor through the redisplay interface)

[GNU bug Tracking System]

Your message dated Thu, 24 Oct 2019 11:34:01 -0300
with message-id <CAELgYhd2HH=W9qg5nAKpujL6XanfmSc2Kyp_=address@hidden>
and subject line Re: bug#37770: [PATCH] Expose scale factor through the 
redisplay interface
has caused the debbugs.gnu.org bug report #37770,
regarding [PATCH] Expose scale factor through the redisplay interface
to be marked as done.

(If you believe you have received this mail in error, please contact
address@hidden.)


-- 
37770: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=37770
GNU Bug Tracking System
Contact address@hidden with problems

--- Begin Message --- Subject: [PATCH] Expose scale factor through the redisplay interface Date: Tue, 15 Oct 2019 19:29:58 -0300

I need this in order to move forward #37689.

Besides I did some related changes proposed in #37752, which I'm no
closing in favor of this one.

Here is the commit message:

    * src/dispextern.h: add get_scale_factor API.
    * src/xterm.c:
      - Unify usages of xg_get_scale and x_get_scale_factor into a
        consolidated x_get_scale_factor that is exported by the rif.
      - Simplify scale inferring logic (see note below).
    * src/w32term.c:
      - Simplify w32_get_scale_factor in a similar way (see note).
      - Add it to the rif.
    * src/nsterm.m:
      - Just add NULL to the rif since there are no uses of any scale
        factor here. Clients are expected to interpret a missing API
        as meaning scale factor = 1.

    Note: both x_get_scale_factor and w32_get_scale_factor computed
    distinct scales for x and y by taking the ratio between effective
    resolution in each direction and a standard 96 dpi resolution.  Since
    this ratio is then truncated to an integer (the floor) it seems to me
    that there is no sensible possibility that these two numbers
    diverge. Moreover, modern toolkits report one number as scale factor
    and we need a common interface here. For those reasons I'm arbitrarily
    picking the horizontal scale factor as THE scale factor.

Best regards
--
Carlos

0001-Expose-scale-factor-through-the-redisplay-interface.patch
Description: Text Data

--- End Message ---

--- Begin Message --- Subject: Re: bug#37770: [PATCH] Expose scale factor through the redisplay interface Date: Thu, 24 Oct 2019 11:34:01 -0300

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

--- End Message ---