[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#37770: [PATCH] Expose scale factor through the redisplay interface
From: |
Robert Pluim |
Subject: |
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@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
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/15
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/15
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Robert Pluim, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/16
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Robert Pluim, 2019/10/17
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Eli Zaretskii, 2019/10/20
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/20
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/22
- bug#37770: [PATCH] Expose scale factor through the redisplay interface,
Robert Pluim <=
- bug#37770: [PATCH] Expose scale factor through the redisplay interface, Carlos Pita, 2019/10/24