bug#31223: [PATCH] Fix empty/incorrect GTK menus on HiDPI monitors with window scaling factor > 1

[Robert Pluim]

>>>>> On Tue, 03 Dec 2019 09:22:16 +0100, Robert Pluim <rpluim@gmail.com> said:

    Robert> Iʼll leave the bug open until I get a chance to verify the
    Robert> multi-monitor cases.

So the multi-monitor case is either interesting or annoying, depending
on your point of view.

Under Wayland GTK supports per-monitor scaling values, and returns
scaled values for the geometry of the monitors, so normally you'd need
to scale width/height and the coordinates of the top left corner for
each monitor. However, let's say you have two monitors next to each
other, with the tops aligned:

A: 3840x2160 | B: 1920x1080

with scaling factors A: 2, B: 1

You'd want to report the geometry of B as

(3840 0 1920 1080)

but because the GTK API gives you scaled values, it becomes

(1920 0 1920 1080)

which is incoherent with the workarea, where we are scaling back up:

(3840 0 1920 1080)

Normally you wouldnʼt know that you need to scale this by 2, except
that the scaling factor of B is actually reported as 2, not 1, so
applying scaling gets us the right answer. This 'error' in reporting
the scaling factor is because Emacs is not a pure GTK application: a
pure GTK application reports 2 and 1 for the scaling factors.

So until Emacs is a pure GTK app [1], I propose the following:

diff --git a/src/xfns.c b/src/xfns.c
index 47aa19607f..51a46bd6db 100644
--- a/src/xfns.c
+++ b/src/xfns.c
@@ -5091,6 +5091,8 @@ DEFUN ("x-display-monitor-attributes-list", 
Fx_display_monitor_attributes_list,
 #elif defined HAVE_GTK3
       scale = gdk_screen_get_monitor_scale_factor (gscreen, i);
 #endif
+      rec.x *= scale;
+      rec.y *= scale;
       rec.width *= scale;
       rec.height *= scale;
       work.x *= scale;

Footnotes:
[1]  When it is, we can stop doing this scaling entirely, the toolkit
     will take care of it for us.