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

[Robert Pluim <rpluim@gmail.com>]

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