bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Ryan Prior]

I'm on Ubuntu 14.04.3 using a Dell XPS 13, which has screen resolution
3200x1800. In order to make the menus large enough to read, the screen
is scaled at x2.

However, at that scale setting, Emacs shows tooltips and menus at an
offset a few inches down and to the right of the mouse pointer.

Using the settings panel I can change the scaling factor. If I reduce it
below 2, for example to 1.88, then Emacs displays menus and tooltips
where I would expect. At a scale setting equal to or higher than 2x, the
menus and tooltips are shifted down and to the right.



In GNU Emacs 25.0.50.3 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8)
 of 2015-08-25
Repository revision: ef4c2eac6c6e1df8f40efde52d737d911cf2dcf9
Windowing system distributor `The X.Org Foundation', version 11.0.11501000
System Description:    Ubuntu 14.04.3 LTS

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GCONF GSETTINGS
NOTIFY LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB
TOOLKIT_SCROLL_BARS GTK3 X11

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  delete-selection-mode: t
  global-anzu-mode: t
  anzu-mode: t
  diff-auto-refine-mode: t
  global-auto-complete-mode: t
  auto-complete-mode: t
  origami-mode: t
  show-paren-mode: t
  global-hl-line-mode: t
  desktop-save-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-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: t

Recent messages:
Loading desktop...done
Loading hl-line...done
Loading paren...done
Making url-show-status local to  *http 127.0.0.1:60551* while let-bound!
Wrote /home/ryan/.emacs.d/.emacs.desktop.lock
Desktop: 1 frame, 5 buffers restored.
For information about GNU Emacs and the GNU system, type C-h C-a.
user-error: Beginning of history; no preceding item
user-error: End of history; no default available

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message format-spec rfc822 mml mml-sec
mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader sendmail
mail-utils delight delsel dired-x solarized-theme solarized-definitions
markdown-mode noutline outline autorevert filenotify dired anzu flymake
compile comint ansi-color ring vc vc-dispatcher vc-git diff-mode
network-stream nsm starttls tern-auto-complete auto-complete popup tern
easy-mmode url-http tls url-auth mail-parse rfc2231 rfc2047 rfc2045
ietf-drums url-gw url url-proxy url-privacy url-expand url-methods
url-history url-cookie url-domsuf url-util url-parse auth-source cl-seq
eieio eieio-core cl-macs gnus-util mm-util help-fns mail-prsvr
password-cache url-vars mailcap edmacro kmacro origami origami-parsers
cl gv s ucs-normalize dash js advice byte-opt bytecomp byte-compile
cl-extra help-mode cconv json imenu thingatpt cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs finder-inf
go-mode-autoloads info package easymenu epg-config paren hl-line desktop
frameset cl-loaddefs pcase cl-lib cus-start cus-load time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt
fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register
page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock
font-lock syntax facemenu font-core frame cl-generic cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese charscript case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice
loaddefs button faces cus-face macroexp files text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote dbusbind inotify dynamic-setting
system-font-setting font-render-setting move-toolbar gtk x-toolkit x
multi-tty make-network-process emacs)

Memory information:
((conses 16 345073 13391)
 (symbols 48 32645 0)
 (miscs 40 334 142)
 (strings 32 55155 9852)
 (string-bytes 1 1623474)
 (vectors 16 47253)
 (vector-slots 8 817466 5450)
 (floats 8 250 54)
 (intervals 56 393 0)
 (buffers 976 16)
 (heap 1024 29843 1634))

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Eli Zaretskii]

> From: Ryan Prior <ryanprior@gmail.com>
> Date: Tue, 25 Aug 2015 17:51:28 -0500
> 
> I'm on Ubuntu 14.04.3 using a Dell XPS 13, which has screen resolution
> 3200x1800. In order to make the menus large enough to read, the screen
> is scaled at x2.

What does that mean?  Which pixel coordinates are affected by this,
and how could Emacs know that?

> However, at that scale setting, Emacs shows tooltips and menus at an
> offset a few inches down and to the right of the mouse pointer.
> 
> Using the settings panel I can change the scaling factor. If I reduce it
> below 2, for example to 1.88, then Emacs displays menus and tooltips
> where I would expect. At a scale setting equal to or higher than 2x, the
> menus and tooltips are shifted down and to the right.

Sounds like some X API calls lie to us, but it's impossible to fix
this without knowing which ones.

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[martin rudalics]

 >> I'm on Ubuntu 14.04.3 using a Dell XPS 13, which has screen resolution
 >> 3200x1800. In order to make the menus large enough to read, the screen
 >> is scaled at x2.
 >
 > What does that mean?  Which pixel coordinates are affected by this,
 > and how could Emacs know that?

Via gtk_widget_get_scale_factor, I suppose.

 > Sounds like some X API calls lie to us, but it's impossible to fix
 > this without knowing which ones.

In any case it will be a pain to fix this :-(

martin

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Eli Zaretskii]

> Date: Wed, 26 Aug 2015 10:56:32 +0200
> From: martin rudalics <rudalics@gmx.at>
> CC: 21348@debbugs.gnu.org
> 
>  >> I'm on Ubuntu 14.04.3 using a Dell XPS 13, which has screen resolution
>  >> 3200x1800. In order to make the menus large enough to read, the screen
>  >> is scaled at x2.
>  >
>  > What does that mean?  Which pixel coordinates are affected by this,
>  > and how could Emacs know that?
> 
> Via gtk_widget_get_scale_factor, I suppose.

But if GTK knows about that, shouldn't it DTRT with tooltips
automagically?  In a GTK build the tooltips are presented by GTK,
right?

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Glenn Morris]

I assume this is the same as bug#20619 (see also #18429).
Jan thought it would be "a huge undertaking" to fix.
But presumably such issues will become increasingly common.

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[martin rudalics]

 > But if GTK knows about that, shouldn't it DTRT with tooltips
 > automagically?  In a GTK build the tooltips are presented by GTK,
 > right?

Not necessarily.  For example I build without them because they are
ugly.

I don't understand yet where this scaling takes place.  If we only have
problems to change window coordinates to display coordinates, the
problem should be manageable.

martin

bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[martin rudalics]

 > I'm on Ubuntu 14.04.3 using a Dell XPS 13, which has screen resolution
 > 3200x1800. In order to make the menus large enough to read, the screen
 > is scaled at x2.
 >
 > However, at that scale setting, Emacs shows tooltips and menus at an
 > offset a few inches down and to the right of the mouse pointer.
 >
 > Using the settings panel I can change the scaling factor. If I reduce it
 > below 2, for example to 1.88, then Emacs displays menus and tooltips
 > where I would expect. At a scale setting equal to or higher than 2x, the
 > menus and tooltips are shifted down and to the right.

What does evaluating for a maximized frame

(frame-geometry)

and

(display-monitor-attributes-list)

return for you?  And please tell me whether mouse warping is also
affected by this: Put

(let ((position (window-absolute-pixel-position)))
   (set-mouse-absolute-pixel-position
    (car position) (cdr position)))

into *scratch*, move point after it and type C-x C-e.  Is the mouse
pointer shifted from the upper left corner of the cursor glyph by the
same amount as the menus and tooltips?

martin

bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Ryan Prior]

[-- Attachment #1: Type: text/plain, Size: 1583 bytes --]


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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: patch to fix bugs #21348, #20619 --]
[-- Type: text/x-diff, Size: 3069 bytes --]

From 3addec3d592b9fc81e2a1503a37ccb078f03118c Mon Sep 17 00:00:00 2001
From: Ryan Prior <ryanprior@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

bug#21348: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[martin rudalics]

 > 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

bug#18429: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Ryan Prior]

On Tue, Oct 13, 2015 at 10:51 AM, martin rudalics <rudalics@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

bug#20619: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[martin rudalics]

 > 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

bug#21348: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[Ryan Prior]

On Tue, Oct 13, 2015 at 12:21 PM, martin rudalics <rudalics@gmx.at> wrote:

>  Can you try again with the
> ‘user-position’ frame parameter non-nil?

The behavior is identical.

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

The frame is never flush left except during brief flash. Immediately
afterward, and subsequent to each additional call, the actual frame
position is offset by 20 pixels. This is true for top just as it is
for left.

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

Not quite. With scaling at 2x, the offset is 20 pixels. With scaling
at 1x, the offset is 10 pixels.

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

This question opened a can of worms.

The answer, on Ubuntu Trusty with Unity (Compiz) window manager, is
that it depends on which virtual desktop you are on. I have four
virtual desktops laid out in a 2x2 grid, which I'll refer to clockwise
like so:

[1][2]
[4][3]

On desktop 1, it behaves the same as for a frame which is smaller than
the screen size and not flush with the right screen edge: offset of
(10*scale) pixels when positioning left or top, doesn't appear to
"stick" to anything.

On desktop 2, positioning top behaves the same as desktop 1, but
positioning left results in a frame flush with the left screen edge.
This is not true of frames smaller than the screen size, which I
previously tested on each virtual desktop and displayed consistent
behavior.

On desktop 4, we see a symmetric behavior where positioning left
behaves the same as desktop 1, but positioning top results in a frame
flush with the screen top edge.

On desktop 3, positioning both left and top results in a frame flush
with the respective screen edge, and I observed an additional curious
behavior. Each call to set the top position also decreases the left
position by a small amount, if the number of pixels specified as the
top position is small. In the range of 10-30, it budged the left side;
in the range of 100-500, it didn't.

When I came to write up my results, I decided to try to pin down
exactly where the cut-off was between values which would or wouldn't
budge the frame to the left, so I restarted emacs and set about trying
to reproduce it. But I can't. This time around, a frame larger than
the screen behaves in all ways as I described for desktop 1.

This test could be exercising some little-tested code paths in Emacs,
Unity, or both. As before, I appreciate any assistance in
corroborating and analyzing this information.


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

In fact, mouse-set-absolute-pixel-position works flawlessly as
expected. If I set the frame left position to 0 and the mouse x
position to (10*scale), they line up precisely. Similarly, I can set
the mouse position to (0,0) with no problem.


Ryan

bug#21348: bug#21469: bug#21348: 25.0.50; Screen scaling factor >=2 causes menus, tooltips to display in the wrong place

[martin rudalics]

 >>   Can you try again with the
 >> ‘user-position’ frame parameter non-nil?
 >
 > The behavior is identical.

So Unity seems to ignore ‘user-position’.  Can you manually move
(mouse-drag) the frame to the left edge?  Did you ever try to tweak the
window placement settings in the Compiz Setting Manager?

 >> 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?
 >
 > The frame is never flush left except during brief flash. Immediately
 > afterward, and subsequent to each additional call, the actual frame
 > position is offset by 20 pixels. This is true for top just as it is
 > for left.

I could imagine Unity to not allow the frame enter a 20 pixels zone if
there's some launcher or panel there.  But why should it move a frame
from position 500 to 520?  That simply doesn't make sense.  BTW, does
maximizing the frame horizontally work?  What does evaluating

(set-frame-parameter nil 'fullscreen 'fullwidth)

give?

 >> Does that mean the offset of 20 pixels appears with scaling turned off
 >> and on?
 >
 > Not quite. With scaling at 2x, the offset is 20 pixels. With scaling
 > at 1x, the offset is 10 pixels.

And with scalings 1.5, 2.5 and 3 you consistently get 15, 25 and 30?  If
so then we can conclude that the frame position does not scale with the
x-coordinate Emacs supplies but shifts by the scale factor times ten.

 > The answer, on Ubuntu Trusty with Unity (Compiz) window manager, is
 > that it depends on which virtual desktop you are on. I have four
 > virtual desktops laid out in a 2x2 grid, which I'll refer to clockwise
 > like so:
 >
 > [1][2]
 > [4][3]
 >
 > On desktop 1, it behaves the same as for a frame which is smaller than
 > the screen size and not flush with the right screen edge: offset of
 > (10*scale) pixels when positioning left or top, doesn't appear to
 > "stick" to anything.

So it can't go more to the left or upwards due to the 10*scale
restriction, I suppose.

 > On desktop 2, positioning top behaves the same as desktop 1, but
 > positioning left results in a frame flush with the left screen edge.
 > This is not true of frames smaller than the screen size, which I
 > previously tested on each virtual desktop and displayed consistent
 > behavior.

You mean that a large frame on desktop 2 gets flushed left, a smaller
one gets still set off at the 10*scale position.

 > On desktop 4, we see a symmetric behavior where positioning left
 > behaves the same as desktop 1, but positioning top results in a frame
 > flush with the screen top edge.

Sounds consistent.

 > On desktop 3, positioning both left and top results in a frame flush
 > with the respective screen edge, and I observed an additional curious
 > behavior. Each call to set the top position also decreases the left
 > position by a small amount, if the number of pixels specified as the
 > top position is small. In the range of 10-30, it budged the left side;
 > in the range of 100-500, it didn't.

In all these calls did you also specify a left position or did you only
specify the top position?

 > When I came to write up my results, I decided to try to pin down
 > exactly where the cut-off was between values which would or wouldn't
 > budge the frame to the left, so I restarted emacs and set about trying
 > to reproduce it. But I can't. This time around, a frame larger than
 > the screen behaves in all ways as I described for desktop 1.

That is the behavior on desktop 4 is the same as the behavior on desktop
1: A 10*scale pixel zone on the left and the top are left free?

 > This test could be exercising some little-tested code paths in Emacs,
 > Unity, or both.

Apart from occasional specifications like (0, 0) or a user supplied
position, Emacs never tries to enforce a particular frame position.
Also, Emacs nowhere samples the screen size in order to get a fitting
initial size of the frame.  The default size of the initial frame is
80x35 characters, hardcoded somewhere in frame.c.

So all this positioning stuff should be in Unity.  How they could
possibly have coded such a thing is a mystery to me.

 >> And does ‘set-mouse-absolute-pixel-position’ work normally?
 >
 > In fact, mouse-set-absolute-pixel-position works flawlessly as
 > expected. If I set the frame left position to 0 and the mouse x
 > position to (10*scale), they line up precisely.

OK.  One problem less to care about.

 > Similarly, I can set
 > the mouse position to (0,0) with no problem.

‘set-mouse-absolute-pixel-position’ operates on the "default root
window" of the selected frame's display.  Does
‘set-mouse-pixel-position’ also work as expected?  For example, does

(set-mouse-pixel-position (selected-frame) 0 0)

correctly move the mouse pointer to a position right under the start of
the menu or tool bar?

martin