GNU bug report logs - #20619
24.5; Pop-up menus clipped on HiDPI (Gtk3/X11)

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 20619 in the body.
You can then email your comments to 20619 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Michael Droettboom <mdroe <at> stsci.edu>
To: <bug-gnu-emacs <at> gnu.org>
Subject: 24.5; Pop-up menus clipped on HiDPI (Gtk3/X11)
Date: Wed, 20 May 2015 14:20:12 -0400

If in HiDPI mode on Linux [1] the popup menus are constrained to the
upper left quadrant of the screen and are not opened near the mouse
cursor. For example, 'C-mouse-1' in the lower-right hand quadrant opens
an empty menu. 'C-mouse-1' in the upper-right hand quadrant opens a
menu, but not in the correct location.

[1] This mode is set automatically under Gnome, or may get set manually
with:

gsettings set org.gnome.desktop.interface scaling-factor 2

A workaround, which may help to diagnose the bug, is to start emacs
using:

GDK_SCALE=0.5 emacs

Other Gtk3 applications (gnome-terminal, nautilus) so not seem to
exhibit this behavior under the same conditions.



In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2)
of 2015-04-22 on buildhw-08.phx2.fedoraproject.org
Windowing system distributor `Fedora Project', version 11.0.11701000
System Description: Fedora release 23 (Rawhide)

Configured using:
`configure --build=x86_64-redhat-linux-gnu
--host=x86_64-redhat-linux-gnu --program-prefix=
--disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
--bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
--datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
--libexecdir=/usr/libexec --localstatedir=/var
--sharedstatedir=/var/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
--with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
--with-gpm=no build_alias=x86_64-redhat-linux-gnu
host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
-pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
-grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
-m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'

Important settings:
value of $LC_CTYPE: en_US.utf8
value of $LANG: en_US.utf8
locale-coding-system: utf-8-unix

Message #8 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Michael Droettboom <mdroe <at> stsci.edu>, 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: 24.5; Pop-up menus clipped on HiDPI (Gtk3/X11)
Date: Sat, 23 May 2015 14:06:23 +0200

Hi.

Den 2015-05-20 20:20, Michael Droettboom skrev:
>
> If in HiDPI mode on Linux [1] the popup menus are constrained to the
> upper left quadrant of the screen and are not opened near the mouse
> cursor. For example, 'C-mouse-1' in the lower-right hand quadrant opens
> an empty menu. 'C-mouse-1' in the upper-right hand quadrant opens a
> menu, but not in the correct location.
>
> [1] This mode is set automatically under Gnome, or may get set manually
> with:
>
> gsettings set org.gnome.desktop.interface scaling-factor 2
>
> A workaround, which may help to diagnose the bug, is to start emacs
> using:
>
> GDK_SCALE=0.5 emacs

This is a huge undertaking, that requires changes in Emacs all over the place. 
 Coordinates and sizes are used in many places.
I'm not sure its worth it, as this Gnome thing is a bad way to scale 
applications (it requires applications to conform to Gtk+).
KDE does something different for example.  So I'm guessing something better 
will emerge.

>
> Other Gtk3 applications (gnome-terminal, nautilus) so not seem to
> exhibit this behavior under the same conditions.

Emacs is not a Gtk3 application, ut just uses some of its widgets.
Its more of a raw X11/Gtk3 hybrid.

	Jan D.

>
>
>
> In GNU Emacs 24.5.1 (x86_64-redhat-linux-gnu, GTK+ Version 3.16.2)
> of 2015-04-22 on buildhw-08.phx2.fedoraproject.org
> Windowing system distributor `Fedora Project', version 11.0.11701000
> System Description: Fedora release 23 (Rawhide)
>
> Configured using:
> `configure --build=x86_64-redhat-linux-gnu
> --host=x86_64-redhat-linux-gnu --program-prefix=
> --disable-dependency-tracking --prefix=/usr --exec-prefix=/usr
> --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc
> --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib64
> --libexecdir=/usr/libexec --localstatedir=/var
> --sharedstatedir=/var/lib --mandir=/usr/share/man
> --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
> --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
> --with-gpm=no build_alias=x86_64-redhat-linux-gnu
> host_alias=x86_64-redhat-linux-gnu 'CFLAGS=-DMAIL_USE_LOCKF -O2 -g
> -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2
> -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4
> -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
> -m64 -mtune=generic' LDFLAGS=-Wl,-z,relro'
>
> Important settings:
> value of $LC_CTYPE: en_US.utf8
> value of $LANG: en_US.utf8
> locale-coding-system: utf-8-unix
>
>
>
>

Message #13 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <ryanprior <at> gmail.com>
To: 21348 <at> debbugs.gnu.org
Cc: 20619 <at> debbugs.gnu.org, 18429 <at> debbugs.gnu.org, 21469 <at> debbugs.gnu.org
Subject: Re: bug#21348: 25.0.50;
 Screen scaling factor >=2 causes menus, tooltips to display in the
 wrong place
Date: Mon, 12 Oct 2015 16:10:52 -0500

[Message part 1 (text/plain, inline)]

I wrote a patch to fix the issues from bugs #20619 and #21348 for GTK
users. When the functions to display a tooltip or menu are called, Emacs
scales coordinates using a factor from GTK. In my testing, non-GTK
tooltips and menus weren't broken, so the problem is specific to GTK and
the patch has no effect on non-GTK builds. Michael Droettboom, will you
apply this patch and verify that the menus are now placed correctly on
your system?

There's something else entirely going on with the scroll bars in bug
#21469, this patch doesn't address that at all. I had never noticed that
hidpi bug because I dont use scroll bars, but I can confirm that turning
on scroll bars causes strange behavior. It might be possible that a
similar scaling strategy for scroll bar placement could provide a fix,
so I CC'd that bug. I will investigate that more as time allows.

The final hidpi bug I looked at, #18429, I am unable to
reproduce. Perhaps it is not applicable to my platform - I'm on Ubuntu
Trusty, while the reporter is on Utopic. Anders Kaseorg, can you still
reproduce the bug?

Finally, there's the open question of why the coordinates these
functions are getting are doubled in the first place. Given my limited
familiarity with Emacs internals, I have not made any progress on that
question. Perhaps there are few enough places where these
sometimes-inflated coordinates are passed into GTK that we can just
scale them everywhere and call it good enough. Or perhaps there's a more
robust solution somewhere else - if anybody can help explain this to me,
I would be appreciative.

[0001-Adjust-overlay-position-on-hidpi-screens.patch (text/x-diff, inline)]

From 3addec3d592b9fc81e2a1503a37ccb078f03118c Mon Sep 17 00:00:00 2001
From: Ryan Prior <ryanprior <at> gmail.com>
Date: Fri, 2 Oct 2015 19:22:28 -0500
Subject: [PATCH] Adjust overlay position on hidpi screens

Scale the display positions of tooltips and menus according to the
window scaling factor provided by GTK3, if it is available (Bug#21348).
* src/gtkutil.h (xg_scale_x_y_with_widget):
* src/gtkutil.c (xg_scale_x_y_with_widget):
Fuction finds scaling factor and performs scaling.
(xg_show_tooltip): Divide position of tooltip by scaling factor.
* src/xmenu.c (create_and_show_popup_menu) [HAVE_GTK3]:
Divide position of native GTK3 menus by scaling factor.
---
 src/gtkutil.c | 14 ++++++++++++++
 src/gtkutil.h |  4 ++++
 src/xmenu.c   |  6 ++++++
 3 files changed, 24 insertions(+)

diff --git a/src/gtkutil.c b/src/gtkutil.c
index 34e81b5..db80b2e 100644
--- a/src/gtkutil.c
+++ b/src/gtkutil.c
@@ -748,6 +748,7 @@ xg_show_tooltip (struct frame *f, int root_x, int root_y)
   if (x->ttip_window)
     {
       block_input ();
+      xg_scale_x_y_with_widget(GTK_WIDGET(x->ttip_window), &root_x, &root_y);
       gtk_window_move (x->ttip_window, root_x, root_y);
       gtk_widget_show_all (GTK_WIDGET (x->ttip_window));
       unblock_input ();
@@ -3223,6 +3224,19 @@ xg_update_submenu (GtkWidget *submenu,
   return newsub;
 }
 
+/* Scale X and Y.
+   WIDGET the gtk widget from which to get the scaling factor */
+void
+xg_scale_x_y_with_widget (GtkWidget *widget,
+                          int *x,
+                          int *y)
+{
+  gint scale_factor = gtk_widget_get_scale_factor(widget);
+  if(x) *x /= scale_factor;
+  if(y) *y /= scale_factor;
+}
+
+
 /* Update the MENUBAR.
    F is the frame the menu bar belongs to.
    VAL describes the contents of the menu bar.
diff --git a/src/gtkutil.h b/src/gtkutil.h
index 34338db..8db063a 100644
--- a/src/gtkutil.h
+++ b/src/gtkutil.h
@@ -96,6 +96,10 @@ extern GtkWidget *xg_create_widget (const char *type,
                                     GCallback deactivate_cb,
                                     GCallback highlight_cb);
 
+extern void xg_scale_x_y_with_widget (GtkWidget *widget,
+                                      int *x,
+                                      int *y);
+
 extern void xg_modify_menubar_widgets (GtkWidget *menubar,
                                        struct frame *f,
                                        struct _widget_value *val,
diff --git a/src/xmenu.c b/src/xmenu.c
index 192ed89..1b7bbb5 100644
--- a/src/xmenu.c
+++ b/src/xmenu.c
@@ -1229,6 +1229,12 @@ create_and_show_popup_menu (struct frame *f, widget_value *first_wv,
 
                              /* Child of win.  */
                              &dummy_window);
+#ifdef HAVE_GTK3
+      /* Use window scaling factor to adjust position for hidpi screens. */
+      xg_scale_x_y_with_widget(GTK_WIDGET(f->output_data.x->ttip_window),
+                               &x,
+                               &y);
+#endif
       unblock_input ();
       popup_x_y.x = x;
       popup_x_y.y = y;
-- 
2.6.1

Message #16 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ryan Prior <ryanprior <at> gmail.com>, 21348 <at> debbugs.gnu.org
Cc: 20619 <at> debbugs.gnu.org, 18429 <at> debbugs.gnu.org, 21469 <at> debbugs.gnu.org
Subject: Re: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes
 menus, tooltips to display in the wrong place
Date: Tue, 13 Oct 2015 17:51:42 +0200

> I wrote a patch to fix the issues from bugs #20619 and #21348 for GTK
> users. When the functions to display a tooltip or menu are called, Emacs
> scales coordinates using a factor from GTK. In my testing, non-GTK
> tooltips and menus weren't broken, so the problem is specific to GTK and
> the patch has no effect on non-GTK builds.

Thank you very much Ryan.  Your help is very appreciated.

> Michael Droettboom, will you
> apply this patch and verify that the menus are now placed correctly on
> your system?

Michael, pretty please, do that.  If you have any problems applying the
patch or building Emacs, please tell us.  It would be great to fix and
test this before the release.

> There's something else entirely going on with the scroll bars in bug
> #21469, this patch doesn't address that at all. I had never noticed that
> hidpi bug because I dont use scroll bars, but I can confirm that turning
> on scroll bars causes strange behavior.

Is the behavior you see "consistent"?  Robert's screenhots seem to tell
that the x-position of each scrollbar is always twice of what it should
be.

> It might be possible that a
> similar scaling strategy for scroll bar placement could provide a fix,
> so I CC'd that bug. I will investigate that more as time allows.

That would be great.

> The final hidpi bug I looked at, #18429, I am unable to
> reproduce. Perhaps it is not applicable to my platform - I'm on Ubuntu
> Trusty, while the reporter is on Utopic. Anders Kaseorg, can you still
> reproduce the bug?

Let's hope that Anders is listening.

> Finally, there's the open question of why the coordinates these
> functions are getting are doubled in the first place. Given my limited
> familiarity with Emacs internals, I have not made any progress on that
> question. Perhaps there are few enough places where these
> sometimes-inflated coordinates are passed into GTK that we can just
> scale them everywhere and call it good enough.

I don't see any problems with such a solution.

> Or perhaps there's a more
> robust solution somewhere else - if anybody can help explain this to me,
> I would be appreciative.

Are the frame parameters ‘top’ and ‘left’ affected?  Suppose you do say
(set-frame-parameter nil 'left 500) with scaling in effect.  Does the
frame appear 500 pixels left of the left screen edge?  If not, then
mouse warping (‘set-mouse-absolute-pixel-position’) is probably affected
too and we really have to look into a more generic solution.

martin

Message #19 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Ryan Prior <ryanprior <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20619 <at> debbugs.gnu.org, 18429 <at> debbugs.gnu.org, 21348 <at> debbugs.gnu.org,
 21469 <at> debbugs.gnu.org
Subject: Re: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes
 menus, tooltips to display in the wrong place
Date: Tue, 13 Oct 2015 11:34:34 -0500

On Tue, Oct 13, 2015 at 10:51 AM, martin rudalics <rudalics <at> gmx.at> wrote:

> Are the frame parameters ‘top’ and ‘left’ affected?  Suppose you do say
> (set-frame-parameter nil 'left 500) with scaling in effect.  Does the
> frame appear 500 pixels left of the left screen edge?  If not, then
> mouse warping (‘set-mouse-absolute-pixel-position’) is probably affected
> too and we really have to look into a more generic solution.

I spent some time playing with frame positions.

TABLE: `(set-frame-parameter nil 'left ,x)
_____________________________________________
x       | actual frame distance from left screen edge (px)
0       | 20
500   | 520
1600 | 1620
1800 | 1772
2000 | 1772

A few observations:
1) offset of 20 pixels
I've never noticed this issue because it doesn't affect maximized
frames. Maybe that number 20 is significant somehow, or perhaps this
is a separate bug. The first time after I start `emacs -Q` and set the
left frame edge to 0, the frame flashes momentarily into place flush
with the left screen edge, for perhaps a single video frame, and then
jumps 20 pixels to the right. Subsequent calls to set the left frame
edge to 0 do not trigger this flashing behavior.
2) numbers are proportional, modulo the unexplained offset
We do not see doubling behavior here. I have added no scaling code
pertaining to frame positioning.
3) frame "sticks" to the right screen edge
Given the width of the frame I was testing with, when the left frame
edge is 1772 pixels from the left screen edge, the right frame edge is
flush with the right screen edge. Setting the left frame edge to a
greater value does not result in a further movement of the frame.

l appreciate any help with corroboration and analysis of these results.

Yours,
Ryan

Message #22 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Ryan Prior <ryanprior <at> gmail.com>
Cc: 20619 <at> debbugs.gnu.org, 18429 <at> debbugs.gnu.org, 21348 <at> debbugs.gnu.org,
 21469 <at> debbugs.gnu.org
Subject: Re: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes
 menus, tooltips to display in the wrong place
Date: Tue, 13 Oct 2015 19:21:41 +0200

> TABLE: `(set-frame-parameter nil 'left ,x)
> _____________________________________________
> x       | actual frame distance from left screen edge (px)
> 0       | 20
> 500   | 520
> 1600 | 1620
> 1800 | 1772
> 2000 | 1772
>
> A few observations:
> 1) offset of 20 pixels
> I've never noticed this issue because it doesn't affect maximized
> frames. Maybe that number 20 is significant somehow, or perhaps this
> is a separate bug. The first time after I start `emacs -Q` and set the
> left frame edge to 0, the frame flashes momentarily into place flush
> with the left screen edge, for perhaps a single video frame, and then
> jumps 20 pixels to the right.

This might be window manager related.  Can you try again with the
‘user-position’ frame parameter non-nil?  Like

(modify-frame-parameters nil '((left . 0) (user-position . t)))

> Subsequent calls to set the left frame
> edge to 0 do not trigger this flashing behavior.

You mean on a subsequent attempt the frame is flushed left or still at
position 20.  What happens when you try something similar with the ‘top’
parameter?

> 2) numbers are proportional, modulo the unexplained offset
> We do not see doubling behavior here. I have added no scaling code
> pertaining to frame positioning.

Does that mean the offset of 20 pixels appears with scaling turned off
and on?

> 3) frame "sticks" to the right screen edge
> Given the width of the frame I was testing with, when the left frame
> edge is 1772 pixels from the left screen edge, the right frame edge is
> flush with the right screen edge. Setting the left frame edge to a
> greater value does not result in a further movement of the frame.

So the window manager probably constrains frame positioning.  What
happens with a frame larger than the screen size?

And does ‘set-mouse-absolute-pixel-position’ work normally?

martin

Message #29 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: "C. Scott Ananian" <cscott <at> cscott.net>
To: 20619 <at> debbugs.gnu.org
Subject: Another HiDPI issue
Date: Wed, 11 May 2016 11:02:05 -0400

[Message part 1 (text/plain, inline)]

In addition to the pop-up menus being misplaced, on my machine
(debian/testing, HiDPI=2, emacs 24.5.1) I'm seeing the initial window sizes
being much too wide.  The scaling from columns from font-size seems to be
broken, because when I resize the window emacs claims the window is "80x24"
but in reality it is much wider (I'm guessing twice as wide).
  --scott

-- 
                         ( http://cscott.net/ )

[Message part 2 (text/html, inline)]

Message #32 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: "C. Scott Ananian" <cscott <at> cscott.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Another HiDPI issue
Date: Mon, 16 May 2016 14:31:04 -0400

[Message part 1 (text/plain, inline)]

I read the patch and did not see anywhere where it affected the main window
size. The changes appear to be isolated to the position of popups; in
particular the only functions modified are `xg_show_tooltip` and
`create_and_show_popup_menu`.  I am happy to try a patch if it will address
the main window size issues I am seeing.
  --scott
​

[Message part 2 (text/html, inline)]

Message #35 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "C. Scott Ananian" <cscott <at> cscott.net>, 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Another HiDPI issue
Date: Mon, 16 May 2016 10:20:38 +0200

> In addition to the pop-up menus being misplaced, on my machine
> (debian/testing, HiDPI=2, emacs 24.5.1) I'm seeing the initial window sizes
> being much too wide.  The scaling from columns from font-size seems to be
> broken, because when I resize the window emacs claims the window is "80x24"
> but in reality it is much wider (I'm guessing twice as wide).

Did you ever try the patch submitted to this thread?

martin

Message #38 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: "C. Scott Ananian" <cscott <at> cscott.net>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Another HiDPI issue
Date: Wed, 18 May 2016 09:00:49 +0200

> I read the patch and did not see anywhere where it affected the main window
> size. The changes appear to be isolated to the position of popups; in
> particular the only functions modified are `xg_show_tooltip` and
> `create_and_show_popup_menu`.  I am happy to try a patch if it will address
> the main window size issues I am seeing.

Ryan Prior has written a patch for the original problem posted in this
thread.  Unfortunately, Michael Droettboom (the poster of the problem)
never responded and neither did other persons who reported similar
problems.  In December, for example, David Christiansen promised to test
Ryan's patch as soon as he would get home from honeymoon.  Apparently he
never did ...

Since you are able to reproduce the problem, it would have been a nice
gesture if you applied the patch and tested whether it resolves the
original problem.  Maybe this way you could have provided sufficient
motivation for Ryan to investigate the problem you see too.  As it
stands, it's virtually impossible to convince HiDPI users to test Ryan's
patch and we very likely lost another contributor.

martin

Message #41 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: "C. Scott Ananian" <cscott <at> cscott.net>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Another HiDPI issue
Date: Wed, 18 May 2016 08:20:45 -0400

[Message part 1 (text/plain, inline)]

It's not like it's hard to reproduce: download gnome-tweak-tool and set
your scaling factor to 2.  It doesn't require any special hardware.

[Message part 2 (text/html, inline)]

Message #44 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: "C. Scott Ananian" <cananian <at> gmail.com>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Another HiDPI issue
Date: Wed, 18 May 2016 08:24:19 -0400

[Message part 1 (text/plain, inline)]

What would be *more* useful, instead of guilt-tripping contributors, is to
offer some technical advice on the issue: where my program is likely to be
fine, what part of the code I might consider reading, and useful insight at
all.  Then you might motivate me to scratch my own itch and *gain* a
contributor.  Instead you are in the process of losing two.
On May 18, 2016 8:20 AM, "C. Scott Ananian" <cscott <at> cscott.net> wrote:

It's not like it's hard to reproduce: download gnome-tweak-tool and set
your scaling factor to 2.  It doesn't require any special hardware.

[Message part 2 (text/html, inline)]

Message #47 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: cscott <at> cscott.net
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Another HiDPI issue
Date: Thu, 19 May 2016 14:55:04 +0200

> It's not like it's hard to reproduce: download gnome-tweak-tool and set
> your scaling factor to 2.  It doesn't require any special hardware.

ISTR that Glenn already proposed something similar.  But I don't use
GNOME.  I use xfce and spent an entire afternoon to make xfce accept the
resolution of my display.  The only things I remember about that is that
there's hardly anything useful to be found about this issue on the Web
and that I had to resort to some non-standard means to have my settings
restored in subsequent sessions.  I'm simply too afraid to break these
settings by simulating a fictitious high resolution display.

> What would be *more* useful, instead of guilt-tripping contributors, is to
> offer some technical advice on the issue: where my program is likely to be
> fine, what part of the code I might consider reading, and useful insight at
> all.  Then you might motivate me to scratch my own itch and *gain* a
> contributor.  Instead you are in the process of losing two.

Offering technical advice on this issue is not easy for me.  In the
first place I've so far not been able to understand what the HiDPI
scaling issue is all about.  I presume that font scaling is left to the
application which means for Emacs that users who have set their HiDPI
scaling factor to two usually will select a default font twice the usual
size.  Icon scaling is presumably also left to the application which
probabaly means that the Emacs tool bar on a HiDPI scaled display looks
very tiny.  Are these assumptions correct?

If so, scaling probably affects only the sizes and position of windows
including subwindows and widgets for menus, scrollbars and tooltips
needed to make the appearance of Emacs frames coherent.  I said
"probably" because the bug descriptions I've red so far do not allow me
to draw a precise conclusion.  Maybe we should resolve that issue first
(see also my questions to Ryan in the thread of bug#20619): Which
behaviors are reproducible under which desktop environments, toolkits
etc.

Now in the thread on bug#20619 Jan said that

  This is a huge undertaking, that requires changes in Emacs all over
  the place.  Coordinates and sizes are used in many places.

But IIUC we do have to identify and change only those places where Emacs
passes/receives coordinates to/from the operating system, window
manager, or toolkit.  Internally, Emacs will proceed to think in its own
coordinates.  And apparently we have to do that only for the gtk build.
Do these assumptions make sense?

Now IIUC again Ryan has already provided a solution for the positioning
of popup menus and tooltips.  IMO we would have to first check whether
his approach to use xg_scale_x_y_with_widget is correct and popup menus
and tooltips are placed correctly wrt a (probably only fictitiously)
correctly positioned frame.  If so we can see whether that function can
be used for the remaining elements as well.  WDYT?

martin

Message #50 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
To: 20619 <at> debbugs.gnu.org
Subject: Improving HiDPI experience with emacs
Date: Thu, 22 Dec 2016 16:33:19 +0100

Hi,

I have just enabled hidpi on my screen and noticed that emacs has 
several issues I would really like to see them fixed, since I use it 
extensively.  (For those interested, I also wrote yesterday a page about 
my experiences at http://eugen.dedu.free.fr/docs/hidpi.html.)

I do not use GNOME, but awesome.  I just set GDK_SCALE=2 to have 
hidpi-aware applications, and this works on several applications.

Everyone can test with "GDK_SCALE=X emacs", with X=1 (for normal screen, 
default value) and X=2 for hidpi.

Is there any emacs developer wanting to fix this behaviour?  I can test 
patches if needed (hope it is not harder than other applications).

I use emacs 25.1.1 on debian.

Best regards,
-- 
Eugen

Message #53 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
To: 20619 <at> debbugs.gnu.org
Subject: Scrollbars
Date: Fri, 23 Dec 2016 21:30:17 +0100

So I have successfully compiled emacs 25.1.1 to make tests.

I applied the patch given in message #13, but it works partially, I will 
discuss about it later.

Now, to advance emacs support for HIDPI I would like to fix the 
scrollbar.  Do all people here agree that the scrollbar has a width 
twice as normal?  The reason is that in src/gtkutil.c there is this code:

int
xg_get_default_scrollbar_width (void)
{
  return scroll_bar_width_for_theme * xg_get_gdk_scale ();
}

where xg_get_gdk_scale returns GDK_SCALE variable, i.e. 2 in general.

If I replace with:
  return scroll_bar_width_for_theme;
the scrollbar is shown correctly.

This change was made by 
https://github.com/emacs-mirror/emacs/commit/c0055ff5b03c9121ab5bf752496b09416f0f0a7d. 
 I think there was an error there, or perhaps in the mean time (since 
May 2015) GTK has changed in a way so that scrollbars are taken into 
account.

Anyway, using "GTK_SCALE=2 emacs" shows correctly the scrollbar with my 
proposition.

Note that GDK_DPI_SCALE is only for font, AFAIU from 
https://developer.gnome.org/gtk3/stable/gtk-x11.html.

What do you think?  Would you commit such a modification?

I would like to look into other issues as well.

Message #56 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Scrollbars
Date: Sat, 24 Dec 2016 09:56:53 +0200

> From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
> Date: Fri, 23 Dec 2016 21:30:17 +0100
> 
> Now, to advance emacs support for HIDPI I would like to fix the 
> scrollbar.  Do all people here agree that the scrollbar has a width 
> twice as normal?  The reason is that in src/gtkutil.c there is this code:
> 
> int
> xg_get_default_scrollbar_width (void)
> {
>    return scroll_bar_width_for_theme * xg_get_gdk_scale ();
> }
> 
> where xg_get_gdk_scale returns GDK_SCALE variable, i.e. 2 in general.
> 
> If I replace with:
>    return scroll_bar_width_for_theme;
> the scrollbar is shown correctly.
> 
> This change was made by 
> https://github.com/emacs-mirror/emacs/commit/c0055ff5b03c9121ab5bf752496b09416f0f0a7d. 
>   I think there was an error there, or perhaps in the mean time (since 
> May 2015) GTK has changed in a way so that scrollbars are taken into 
> account.

What is your version of GTK?  That commit points to a bug report
(bug#20432), so this change is not a mistake, it did fix a real
problem with scroll bars.  We could make it conditional on the GTK
version, though.  The bug report mentions a specific GTK version.

> Note that GDK_DPI_SCALE is only for font, AFAIU from 
> https://developer.gnome.org/gtk3/stable/gtk-x11.html.

The code you mention doesn't use GDK_DPI_SCALE.

> What do you think?  Would you commit such a modification?

I don't think we can simply revert the change in question, but maybe
we could use different code based on GTK version.

> I would like to look into other issues as well.

Thank you!  I see bugs 20432, 21469, and 18429 that might be relevant.

Message #59 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Scrollbars
Date: Tue, 27 Dec 2016 23:45:24 +0100

On 24/12/16 08:56, Eli Zaretskii wrote:
>> From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
>> Date: Fri, 23 Dec 2016 21:30:17 +0100
>>
>> Now, to advance emacs support for HIDPI I would like to fix the
>> scrollbar.  Do all people here agree that the scrollbar has a width
>> twice as normal?  The reason is that in src/gtkutil.c there is this code:
>>
>> int
>> xg_get_default_scrollbar_width (void)
>> {
>>    return scroll_bar_width_for_theme * xg_get_gdk_scale ();
>> }
>>
>> where xg_get_gdk_scale returns GDK_SCALE variable, i.e. 2 in general.
>>
>> If I replace with:
>>    return scroll_bar_width_for_theme;
>> the scrollbar is shown correctly.
>>
>> This change was made by
>> https://github.com/emacs-mirror/emacs/commit/c0055ff5b03c9121ab5bf752496b09416f0f0a7d.
>>   I think there was an error there, or perhaps in the mean time (since
>> May 2015) GTK has changed in a way so that scrollbars are taken into
>> account.
>
> What is your version of GTK?  That commit points to a bug report
> (bug#20432), so this change is not a mistake, it did fix a real
> problem with scroll bars.  We could make it conditional on the GTK
> version, though.  The bug report mentions a specific GTK version.

I use gtk 3.22.5.

To reproduce the exact environment when that commit was made, I pulled 
the repository at the commit right before that change and compiled it. 
I had one compile error that I fixed with an #undef, and another one:
make[1]: *** [bootstrap-emacs] Segmentation fault
which I have not tried to fix.

>> Note that GDK_DPI_SCALE is only for font, AFAIU from
>> https://developer.gnome.org/gtk3/stable/gtk-x11.html.
>
> The code you mention doesn't use GDK_DPI_SCALE.

Indeed.  I wrote this because in the bug 20432 which the commit fixed it 
was mentioned GDK_DPI_SCALE too.

>> What do you think?  Would you commit such a modification?
>
> I don't think we can simply revert the change in question, but maybe
> we could use different code based on GTK version.

If I make an #ifdef with gtk 3.22, is that fine to do the commit? 
Everyone can test with a gtk-enabled emacs simply using "GDK_SCALE=2 emacs".

>> I would like to look into other issues as well.
>
> Thank you!  I see bugs 20432, 21469, and 18429 that might be relevant.

I have looked at them, but I think the right thing to do is just to fix 
using conditionals, things have changed in the last 1-1.5 years (when 
those bugs were written) it seems.

-- 
Eugen

Message #62 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Scrollbars
Date: Wed, 28 Dec 2016 17:41:13 +0200

> Cc: 20619 <at> debbugs.gnu.org
> From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
> Date: Tue, 27 Dec 2016 23:45:24 +0100
> 
> > What is your version of GTK?  That commit points to a bug report
> > (bug#20432), so this change is not a mistake, it did fix a real
> > problem with scroll bars.  We could make it conditional on the GTK
> > version, though.  The bug report mentions a specific GTK version.
> 
> I use gtk 3.22.5.
> [...]
> >> What do you think?  Would you commit such a modification?
> >
> > I don't think we can simply revert the change in question, but maybe
> > we could use different code based on GTK version.
> 
> If I make an #ifdef with gtk 3.22, is that fine to do the commit? 

Only as the last resort, IMO.  I'd be much happier if someone could
explain how come this is/was a problem for GTK+ v3.16.2, but not for
v3.22.5.  Is it possible to ask someone on some GTK+ forum?  Or maybe
someone who reads this can explain that?

> Everyone can test with a gtk-enabled emacs simply using "GDK_SCALE=2 emacs".

I can't, sadly.

Thanks.

Message #65 received at 20619 <at> debbugs.gnu.org (full text, mbox):

From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 20619 <at> debbugs.gnu.org
Subject: Re: bug#20619: Scrollbars
Date: Wed, 28 Dec 2016 17:35:49 +0100

On 28/12/16 16:41, Eli Zaretskii wrote:
>> Cc: 20619 <at> debbugs.gnu.org
>> From: Eugen Dedu <eugen.dedu <at> univ-fcomte.fr>
>> Date: Tue, 27 Dec 2016 23:45:24 +0100
>>
>>> What is your version of GTK?  That commit points to a bug report
>>> (bug#20432), so this change is not a mistake, it did fix a real
>>> problem with scroll bars.  We could make it conditional on the GTK
>>> version, though.  The bug report mentions a specific GTK version.
>>
>> I use gtk 3.22.5.
>> [...]
>>>> What do you think?  Would you commit such a modification?
>>>
>>> I don't think we can simply revert the change in question, but maybe
>>> we could use different code based on GTK version.
>>
>> If I make an #ifdef with gtk 3.22, is that fine to do the commit?
>
> Only as the last resort, IMO.  I'd be much happier if someone could
> explain how come this is/was a problem for GTK+ v3.16.2, but not for
> v3.22.5.  Is it possible to ask someone on some GTK+ forum?  Or maybe
> someone who reads this can explain that?

Just for information, I looked also in the NEWS file of GTK and have not 
seen anything about the scrolllbars between 3.16.2 and 3.22.5.

-- 
Eugen

Previous Next

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