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

[Dmitry Gutov]

On 26.01.2020 20:38, martin rudalics wrote:

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

I should see if my old laptop is still functional when I'm near 
geographically (maybe tomorrow).

Speaking of old laptops, my offer regarding help installing GNOME or 
sending a newer video card still stands. Although I'm guessing, given an 
old enough system, you might have to change both the MB and CPU as well.

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

I'm guessing you could be more sensitive to GC pauses. My current laptop 
is almost top-of-the-line.

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

Yes. I described that later in the previous email.

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

Same flakiness of behavior also happened the last time I tried this. And 
at that time I didn't change the scale factor at all. Simply: at the 
beginning of the session dragging was smooth, then something happened, 
and it became choppy. And I deleted/created new frames in the meantime.

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

I don't think so. And again, in this instance, both the child frame and 
the normal frame were created after the last change of the scale factor.

I also repeated this experiment at least twice (restarting Emacs in 
between).

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

Could be. But the effect is a lot more pronounced.

>  > Seems so. Aside from the toolbar icons which are not scaled. The 
> context menu appears where it should.
>
> Aha.  Are tooltips well-positioned too?

Yup. Using both Lucid and GTK3.

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

Seem to work, yes. Tested with flymake-mode and tooltip-mode on.

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

The normal frame resizing problem (with drag-internal-border). The icons 
are fine.