Re: slow X11 frame creation and refresh after occlusion

[Greg Klanderman]

>>>>> On February 5, 2021 Robert Pluim <rpluim@gmail.com> wrote:

>>>>> On Thu, 04 Feb 2021 16:14:48 -0500, Greg Klanderman <gak@klanderman.net> 
>>>>> said:
>>>>> On February 4, 2021 Robert Pluim <rpluim@gmail.com> wrote:
>>>>> On Wed, 03 Feb 2021 16:52:15 -0500, Greg Klanderman <gak@klanderman.net> 
>>>>> said:
>>>>> On February 1, 2021 Robert Pluim <rpluim@gmail.com> wrote:
Greg> (frame-parameter nil 'font-backend)
Greg> (xfthb x)

Greg> any suggestions for settings I can try?

>>>>> Configure '--with-cairo'. I'm hoping that will be more efficient in
>>>>> terms of loading fonts.

Greg> OK I will have a look.  Is there any way to determine if font loading
Greg> is causing significant delay?  And would that be an issue on
Greg> subsequent to the first frame on a display?

>>> Emacs does a bunch of font-related stuff every time you create a new
>>> graphical frame. You could try running emacs under 'perf' to see if it
>>> gives any insight.

Greg> OK I built from git, --with-cairo (interestingly configure does not
Greg> fail if you specify --with-cairo but don't have the libraries
Greg> installed) and am able to reproduce the issues I was seeing.

> It?s an option, which means cairo is...optional :-)

Oh, I thought that when you explicitly had a --with-FOO option, it
made it required...

> (I can?t think offhand of an emacs configure option that causes
> configure to fail if it?s not satisfied. Someone will now point one
> out).

I had one that was behaving like that, --with-sound=alsa I think.
I realize that's a little different than a boolean option though.

Greg> It looks like xterm.c has most of the X event handling, so maybe I
Greg> will try to put in some debug prints to see what's going on, or try
Greg> one of the X event tracing programs, or 'perf' next..

> Good luck. You might want to experiment with
>     emacs -xrm "emacs.synchronous: true"
> That would make tracing stuff predictably easier.

OK I will try that resource.

So far I managed to build xtruss and get it working after recursively
debugging a crash where it didn't detect an error opening DISPLAY :10
(which an ssh session already had open).  Thankfully strace quickly
showed the problem and I was able to patch it.

So I have two X event traces for emacs, one under fvwn where it has
the problem and one under cinnamon DE that does not, but have not
gotten far into trying to analyze the differences.  After collecting
the cinnamon DE trace, my laptop wedged and I had to reboot it, it
sometimes does that when VT switching.

But maybe I should re-do with synchronous=true first..

Anyway just based on size there is a significant difference:

% wc -l /tmp/xtruss.emacs.*
  45442 /tmp/xtruss.emacs.bad
   7625 /tmp/xtruss.emacs.good
  53067 total

Both consist of running emacs, moving the frame aside (so second frame
will not be on top), then C-x 5 2, waiting for emacs to be responsive,
then dragging the new frame over the first then leaving it off to the
side, and waiting for emacs to be responsive to input again.  The
final step taking 30-60 sec in the bad case.

Will update if I find anything.

Greg