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

Previous Next

Full log

View this message in rfc822 format

From: Carlos Pita <carlosjosepita <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Robert Pluim <rpluim <at> gmail.com>, 37770 <at> debbugs.gnu.org
Subject: bug#37770: [PATCH] Expose scale factor through the redisplay interface
Date: Tue, 22 Oct 2019 15:06:49 -0300

I've improved the code comment for the redisplay interface entry in:

https://github.com/memeplex/emacs/commit/d3c66e6eea8a3b6f1a269bd968597a3bd8a3e811

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

The new comment states:

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

Some thoughts:

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

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

Previous Next

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