bug#37689: Fringe pixmaps, widgets, etc. look ridiculously tiny in hidpi screen

[Carlos Pita <carlosjosepita@gmail.com>]

> Granted, I prefer the second approach.  We should do as little code duplication as possible.

But we might be duplicating what backends already do.

> I don't think individual backends do any scaling

My understanding is that nowadays everything is up-scaled by the
toolkit, except for fonts that use more sophisticated algorithms to
fit the larger grid of available pixels. So an application using a
modern toolkit should be mostly unaware of screen resolution. In fact,
I've reported some hidpi bugs here and there and, in general, they
were in places where the application did make some explicit geometry
computation based on actual resolution. Or see how "supporting hidpi"
translates in many cases to "port from gtk2 to gtk3". Or look at my
screenshots above, do they look too big? Well, that's because they're
taken from a hidpi screen; now, you might be in a lowdpi one and then
it's obvious that they will look twice as big there; but even if
you're in a hidpi screen I bet you probably will see them doubling the
real thing, because many apps are unaware or ignore the original image
resolution and just let the toolkit show it at 2x. There are plenty of
questions (for both Linux and MacOS) around the web asking "why my
screenshots look too big?", as a cursory google search will show,
although I think the problem was eventually addressed in MacOS,
perhaps in core apps or perhaps in general. That might be the reason
why Alan says that "The only exception is images".

> I think it should be easy to make it do the right thing here.

If you had one single backend this would clearly simplify matters. But
when you had to support three ones, it isn't that clear. Nevertheless,
I think any approach that relies on emacs doing the scaling must be
*carefully* evaluated, because it would mean solving a hard problem
that even toolkits have a hard time to address. Consider for example
having different frames in different monitors each one with its own
dpi and geometry. Are you sure that all geometry/layout computations
for a frame are done by emacs on-the-fly so as they adapt when the
frame is moved from a monitor to another one? Is emacs doing all
geometry calculations itself from the actual device geometry and
resolution or is it most of a hodgepodge, with some things taken care
by the backend and other ones by emacs itself? How clear-cut is the
separation between the stages you mentioned (geometry calculation by
emacs and actual "delivery to the glass" by the backend)? Is it that
clear-cut for *all* supported backends?

Now, that said, I don't think it's a bad idea for emacs to deal with
these matters regardless of its backends (assuming it can force all
backends to work at 1x), since it provides its own toolkit (and its
own OS ;) ). What I would like to know is how close emacs is currently
to one and to the other approach.

> > 2. I'm clueless regarding were widgets (I mean checkboxes and things like that) are rendered.

> I'm not sure I understand how this is related to the issue at hand. Can you elaborate?

By widgets I was referring to the checkboxes, arrows and stuff that
you can see, for example, in a customize-face buffer. When changing
the scaling parameters in x_cr_render_image in emacs 26.3, fringe
bitmaps were affected but those aforementioned widgets weren't. In
emacs 27 they indeed were affected by the same changes in code, but
they looked weirdly distorted and clipped, as you can see in my
previous screenshot. So, in brief, I couldn't locate the C code path
for the rendering of this stuff, specially in emacs 26.3. And by
rendering I was indistinctly referring to both stages you describe.

Best regards
--
Carlos