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

[Dmitry Gutov]

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--set-frame-size
       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.