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

[Ryan Prior <ryanprior@gmail.com>]

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