[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Dmitry Gutov
Subject: Re: Emacs's set-frame-size can not work well with gnome-shell?
Date: Fri, 21 Feb 2020 16:18:47 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.9.0

On 17.02.2020 20:21, martin rudalics wrote:
 > It seems like the optimization I described is sort of already there,
 > at least as far as fit-frame-to-buffer is concerned. So it's better
 > than explicitly cycling frame visibility like I tried before.

Which optimization?

Not resizing frame when set-frame-size doesn't need to (the new size is the same as the old one). Maybe modify-frame-parameters doesn't do the resize. Or the window manager avoids the flicker some other way.

 > When the frame does need to be resized, the flicker is there, of course.

So it doesn't flicker when the frame doesn't need a resize?  Maybe GTK
catches that.

Yup. Maybe.

> But with the current implementation of company-posframe, at least, it might look better than the current behavior also with a GTK2 build. Like, with the new var set to nil (default), the frame is seemingly resized in two steps (*):
 >   - Resize the frame.
>     (redisplay, apparently, but show the previous contents of the buffer)
 >   - Update the contents of the frame.
 >     (redisplay again, apparently)

Have you tried the other way round?

posframe already does it the other way around:

       ;; Replace the posframe buffer contents
      (posframe--insert-string string no-properties)

       posframe height min-height width min-width)

...but the visual effect is how I described above, for some reason.

> The whole process is fast, but not fast enough for me to miss this transition.
> It's either a bug in company-posframe or in Emacs itself, but setting x-gtk-hide-child-frame-during-resize to t at least makes it happen in one move, at the cost of having the whole popup blink at the same time.

I doubt we could collapse the ConfigureNotify and MapNotify into one.
It would be worth a try though ...

> (*) Tried to see the same problem with a Lucid build but couldn't. Maybe just because it resizes faster, IDK.

I doubt that.

The benchmarks that I posted earlier in this discussion did show that Lucid is very fast at resizing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]