GNU bug report logs - #18429
24.3; Emacs window doubles in size upon second focus on high-DPI display

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 18429 in the body.
You can then email your comments to 18429 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: Anders Kaseorg <andersk <at> mit.edu>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.3; Emacs window doubles in size upon second focus on high-DPI
 display
Date: Mon, 8 Sep 2014 14:36:55 -0400 (EDT)

This bug report will be sent to the Bug-GNU-Emacs mailing list
and the GNU bug tracker at debbugs.gnu.org.  Please check that
the From: line contains a valid email address.  After a delay of up
to one day, you should receive an acknowledgment at that address.

Please write in English if possible, as the Emacs maintainers
usually do not have translators for other languages.

Please describe exactly what actions triggered the bug, and
the precise symptoms of the bug.  If you can, give a recipe
starting from `emacs -Q':

1. Start emacs -Q on a high-DPI display.  (Mine is a 15.6″ display
running at 3840×2160, and GNOME automatically selects a scaling factor
of 2.)

2. Unfocus the Emacs window.

3. Refocus the Emacs window.  The window doubles in size!

(As far as I can tell, this only happens the second time Emacs is
focused.)

If Emacs crashed, and you have the Emacs process in the gdb debugger,
please include the output from the following gdb commands:
    `bt full' and `xbacktrace'.
For information about debugging Emacs, please read the file
/usr/share/emacs/24.3/etc/DEBUG.


In GNU Emacs 24.3.1 (x86_64-pc-linux-gnu, GTK+ Version 3.12.2)
 of 2014-09-08 on lgw01-01, modified by Debian
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:	Ubuntu Utopic Unicorn (development branch)

Configured using:
 `configure '--build' 'x86_64-linux-gnu' '--build' 'x86_64-linux-gnu'
 '--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
 '--localstatedir=/var/lib' '--infodir=/usr/share/info'
 '--mandir=/usr/share/man' '--with-pop=yes'
 '--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.3/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3/site-lisp:/usr/share/emacs/site-lisp'
 '--with-crt-dir=/usr/lib/x86_64-linux-gnu' '--with-x=yes'
 '--with-x-toolkit=gtk3' '--with-toolkit-scroll-bars'
 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector-strong
 -Wformat -Werror=format-security -Wall'
 'LDFLAGS=-Wl,-Bsymbolic-functions -Wl,-z,relro'
 'CPPFLAGS=-D_FORTIFY_SOURCE=2''

Important settings:
  value of $LC_MONETARY: en_US.UTF-8
  value of $LC_NUMERIC: en_US.UTF-8
  value of $LC_TIME: en_US.UTF-8
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=uim
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: (only . t)

Recent input:
<down-mouse-1> <drag-mouse-1> M-x r e p o r t - b u 
g <return>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils time-date tooltip ediff-hook vc-hooks
lisp-float-type mwheel x-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment lisp-mode register page menu-bar
rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer loaddefs button faces
cus-face macroexp files text-properties overlay sha1 md5 base64 format
env code-pages mule custom widget hashtable-print-readable backquote
make-network-process dbusbind dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

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

From: Anders Kaseorg <andersk <at> mit.edu>
To: 18429 <at> debbugs.gnu.org
Subject: Re: 24.3; Emacs window doubles in size upon second focus on high-DPI
 display
Date: Tue, 21 Oct 2014 01:28:30 -0400 (EDT)

Things seems to be somewhat better in 24.4.  The initial window size is 
still double what it should be (about 160 chars wide instead of 80), but 
at least it doesn’t double in size again when refocused.

Anders

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

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Anders Kaseorg <andersk <at> mit.edu>, 18429 <at> debbugs.gnu.org
Subject: Re: bug#18429: 24.3; Emacs window doubles in size upon second focus
 on high-DPI display
Date: Thu, 14 May 2015 17:31:20 +0200

Den 2014-10-21 07:28, Anders Kaseorg skrev:
> Things seems to be somewhat better in 24.4.  The initial window size is
> still double what it should be (about 160 chars wide instead of 80), but
> at least it doesn’t double in size again when refocused.
>

Its the gnome scaling factor of 2 that does it.  Emacs is only partly a Gtk+ 
application.  The Gtk+ parts scale, but the Emacs text parts does not.

	Jan D.

Message #14 received at 18429 <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 #17 received at 18429 <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 #20 received at 18429 <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 #23 received at 18429 <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

Previous Next

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