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