GNU bug report logs - #37770
[PATCH] Expose scale factor through the redisplay interface

Previous Next

Full log

Message #32 received at 37770 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Carlos Pita <carlosjosepita <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 37770 <at> debbugs.gnu.org
Subject: Re: bug#37770: [PATCH] Expose scale factor through the redisplay
 interface
Date: Thu, 24 Oct 2019 11:19:24 +0200

>>>>> On Tue, 22 Oct 2019 15:06:49 -0300, Carlos Pita <carlosjosepita <at> gmail.com> said:

    Carlos> I've improved the code comment for the redisplay interface entry in:
    Carlos> https://github.com/memeplex/emacs/commit/d3c66e6eea8a3b6f1a269bd968597a3bd8a3e811

    Carlos> (to generate the patch, add a .patch suffix to that url)

    Carlos> The new comment states:

    Carlos> /* Return the scale factor for the screen containing frame F. All
    Carlos> geometries are reported by the backend using a scale that is
    Carlos> approximately 96dpi x scale_factor. This scale may match
    Carlos> physical resolution or not. */

Two spaces after '.'. Also: "This scale may not match the physical resolution."

    Carlos> Some thoughts:

    Carlos> One possibility for the (maybe distant) future, is that this scale
    Carlos> factor api won't be needed any more. Like nsterm does (I believe), all
    Carlos> backends might expose a 1 x 96dpi interface so that the upper layers
    Carlos> can work mostly or fully unaware of the device complexities. But at
    Carlos> this moment the xterm backend goes to lengths in order to revert gtk
    Carlos> auto-scaling and provide a "physical dpi" (well, not necessarily
    Carlos> physical, since there is still randr in the middle)  interface to the
    Carlos> upper layers, thus losing the benefits of gtk auto-scaling, although
    Carlos> with good reason since nowadays gtk is more of a hack to the x11
    Carlos> backend, sniffing the underlying x event loop as it is, than a proper
    Carlos> backend on its own.

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.

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

    Carlos> Anyway, even if that's not the trend, exposing a higher scale factor
    Carlos> to the upper layers still has the potential benefit of letting those
    Carlos> layers decide how to better use the extra available resolution,
    Carlos> instead of pretending they are drawing to a vintage screen. Whether
    Carlos> this is worthwhile or not I don't know, given that font and image
    Carlos> rendering are the parts most profited from this extra resolution, and
    Carlos> that fact every modern toolkit already exploits. In any case, at this
    Carlos> moment we still need the api because of the differences between
    Carlos> backends.

Youʼre right about that (although on macOS we seem to get by OK
without it).

Robert

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.