Re: Emacs's set-frame-size can not work well with gnome-shell?

[martin rudalics]

>>  > The first experiment: moving the frame by mode-line is smooth.
>>
>> And it's slow with child frames so we have a major difference here.
>> Correct?
>
> It's a very murky story.
>
> I rebuilt with toolkit=lucid, tried the experiment
>
>    => dragging by mode-line was choppy
>
> Changed the scaling factor of the desktop to 100% (everything became tiny on 
my monitor), restarted Emacs.
>
>    => dragging by mode-line was smooth

Don't you have some old laptop somwehere where you could try the
experiments without scaling (I'd never believe that changing scaling
on-the-fly works always in a reproducible fashion).

And, it does _not_ work smoothly here.  I can drag the frame smoothly by
a short distance, then it suddenly jumps, then it drags smoothly again
and so on ...

> BUT dragging the borders to resize had the same problem I reported 
previously, so it's likely not HiDPI related.

Dragging the right and bottom borders too?  Here dragging any border is
usually smooth with very occasional jumps.  But it's much better than
moving.

I can only conclude that someone, somewhere simply drops an entire
sequence of move requests.

> Then I changed scaling back to 200%, restarted Emacs.
>
>    => dragging by mode-line was still smooth (normal frame).

That's what I meant with never to change scaling with a running desktop.
Hot-plugging a scale factor is troublesome like changing the resolution
of the display IMHO.

> Then tried the child-frame example.
>
>    => dragging was choppy. But it resizes smoothly enough when dragged
> by the bottom or right edges. And, more importantly, resizes
> correctly. When dragged by top-left, it resizes choppily, but still
> correctly.
>
> In the same session, I applied your default-frame-alist change and
> created a second "normal" frame. Dragging it by mode-line was choppy
> again.

This again hints at something not really reproducible when changing the
scale factor.

> And resizing it was broken in the same sense I described before
> (and will again clarify below).

> So, in the same session, a child frame and a normal frame have a
> different resizing behavior. A normal frame can move smoothly
> *sometimes*, a child frame always moves choppily.

To a certain degree I see the same here.  Just that resizing a normal
frame is always smooth here.

> When I drag top-left, the bottom-right corner seems to exhibit a more
> gradual drift top-left. When I drag bottom-right, I moves top-left a
> lot more quickly (even if I drag it in the bottom-right direction).

This might be related to the fact that we move and resize in two
distinct steps.  I wrote a function to do both in one step but its
behavior is just broken with pure X-builds and I'm not able to find out
what goes wrong (it doesn't work with normal frames either).

But it obviously might be a by-product of Bug#38452.

> Please note: in most of my experiments I dragged by the corner
> (top-left or bottom-right), and moved in circular-ish, random
> trajectories. This triggers the bug most prominently. But if I just
> grab one border and move the mouse in a straight line, that makes the
> border move in the desired direction, albeit not exactly following the
> mouse cursor (hence the effect, probably).
>
> E.g. if I drag the right border right, it moves after the mouse, but
> more slowly than the mouse. If I move it left, it moves *faster* than
> the mouse. Same with the bottom border. Top and left seem to have a
> similar effect, but less pronounced. Also dragging the top border
> seems to have an effect on the position of the bottom edge (it moves
> up). In all cases, resizing is not smooth.

Both of these hint at Bug#38452.

> Seems so. Aside from the toolbar icons which are not scaled. The context menu 
appears where it should.

Aha.  Are tooltips well-positioned too?

(A side question: Do emacs' native tooltips work with a gtk build -
customizing 'x-gtk-use-system-tooltips' to nil?)

> Also, the GTK3 build seems to have the same problem, and it has had quite a 
few HiDPI patches applied recently.

You mean the icons problem?

> So maybe scaling is not the actual issue (or the jumps would be sharper, this 
just occurred to me).
>
>>  > In the meantime, resizing the first, "normal" frame works okay. Moving
>>  > too (by the title bar).
>>
>> How comes the first frame has a title bar with this specification
>
> Err, it never occurred to me to put this form in the init script.
>
> I launch Emacs, then evaluate this in scratch in the first frame, and then 
press 'C-x 5 2' and experiment with the second frame.
>
>> (setq default-frame-alist
>>        '((minibuffer . nil) (undecorated . t) (drag-with-mode-line . t)
>>      (border-width . 0) (internal-border-width . 8) (drag-internal-border . 
t)
>>      (menu-bar-lines . 0) (tool-bar-lines . 0)))
>>
>>  > GTK:
>>  >
>>  > Actually, similar story with resizing.
>>
>> You mean similar to the Lucid resizing behavior?
>
> Yes (!!). Very similar (maybe exactly the same even).

I just noticed that dragging the left border of a normal GTK frame moves
the right border too here.  So something is rotten.

martin