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

[Dmitry Gutov]

On 25.01.2020 15:10, martin rudalics wrote:
>  > 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

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

Then I changed scaling back to 200%, restarted Emacs.

  => dragging by mode-line was still smooth (normal frame).

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

>  > After that: I tried resizing the dragging the border.
>
> Which border(s)?

Any of them. But:

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).

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.

>  > Apparently, it
>  > doesn't account for window scaling, so it resizes to wrong size, and
>  > the window generally shrinked. After that, moving became choppy as
>  > well. Including after I deleted the resized frame and created new
>  > one(s).
>
> This sounds interesting.  Does scaling work at all with the Lucid build?

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

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

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).

The differences are: child frames do not resize. And dragging them by 
mode-line looks the same as dragging normal ones: move smoothly enough, 
with some drift.

>  > Moving seems smooth enough before and after, with gradual drift toward
>  > top-left (because of the other bug we've mentioned before, probably).
>
> Bug#38452, I presume.

Yes.