[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: slow X11 frame creation and refresh after occlusion
From: |
Robert Pluim |
Subject: |
Re: slow X11 frame creation and refresh after occlusion |
Date: |
Fri, 05 Feb 2021 10:53:51 +0100 |
>>>>> 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 :-)
(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).
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.
Robert