From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Greg Klanderman Newsgroups: gmane.emacs.devel Subject: Re: slow X11 frame creation and refresh after occlusion Date: Fri, 05 Feb 2021 12:12:07 -0500 Message-ID: <874kiq4exk.fsf@lwm.klanderman.net> References: <24567.20346.37031.450073@lwm.klanderman.net> <87eeivwae3.fsf@ericabrahamsen.net> <874kjejezr.fsf@lwm.klanderman.net> <875z3p7stg.fsf@ericabrahamsen.net> <8735yogb1z.fsf@lwm.klanderman.net> <878s8gug2k.fsf@gmail.com> <87tur3ecs0.fsf_-_@lwm.klanderman.net> <87v9biu7js.fsf@gmail.com> <87o8h6dxv7.fsf@lwm.klanderman.net> <877dnstbc5.fsf@gmail.com> <87a6sk4y5s.fsf@lwm.klanderman.net> <87eehws0ix.fsf@gmail.com> <877dnn4jsn.fsf@lwm.klanderman.net> <875z36suvk.fsf@gmail.com> Reply-To: Greg Klanderman Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="14032"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.1008 (Gnus v5.10.8) XEmacs/21.4.24 (linux) Cc: emacs-devel@gnu.org To: Robert Pluim Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 05 19:28:53 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1l85qe-0003W9-Bl for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 19:28:52 +0100 Original-Received: from localhost ([::1]:35596 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1l85qd-0004gk-BX for ged-emacs-devel@m.gmane-mx.org; Fri, 05 Feb 2021 13:28:51 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49554) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1l84eX-0003oR-9M for emacs-devel@gnu.org; Fri, 05 Feb 2021 12:12:18 -0500 Original-Received: from so254-31.mailgun.net ([198.61.254.31]:40629) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1l84eQ-0000iG-Ng for emacs-devel@gnu.org; Fri, 05 Feb 2021 12:12:17 -0500 DKIM-Signature: a=rsa-sha256; v=1; c=relaxed/relaxed; d=klanderman.net; q=dns/txt; s=mg; t=1612545129; h=Content-Type: MIME-Version: References: Message-ID: In-Reply-To: Date: Reply-To: Subject: Cc: To: From: Sender; bh=USVee50b+k9sNdgMX4A8Lw2odOEPuHq6Tsk4ErFGrjY=; b=Y4aeM8lUiSEL9+Sq5NKV2mTGEeWP4I0CUvdt/YuCLFQDDWTlIPg/d/aEcwbDhC140f6tzcjZ 1NrSPNKUM6q43gbmFGfCMkmaB0JHh/MTKrbp9W7mb2nIJBPHrpaGseu+KyYjwvZXgqiNg2NF lFncyOFn59pEXSx4+j65qpJGASI= X-Mailgun-Sending-Ip: 198.61.254.31 X-Mailgun-Sid: WyI5OTUyZSIsICJlbWFjcy1kZXZlbEBnbnUub3JnIiwgIjk3ZGJkOCJd Original-Received: from smtp2.klanderman.net (smtp2.klanderman.net [142.93.10.110]) by smtp-out-n07.prod.us-east-1.postgun.com with SMTP id 601d7c6881f6c45dce3b316e (version=TLS1.3, cipher=TLS_AES_128_GCM_SHA256); Fri, 05 Feb 2021 17:12:08 GMT Original-Received: from lwm.klanderman.net (pool-72-93-77-73.bstnma.fios.verizon.net [72.93.77.73]) by smtp2.klanderman.net (Postfix) with ESMTPSA id 68019415C6; Fri, 5 Feb 2021 12:12:08 -0500 (EST) Original-Received: by lwm.klanderman.net (Postfix, from userid 1000) id 2333C29E437A; Fri, 5 Feb 2021 12:12:08 -0500 (EST) In-Reply-To: <875z36suvk.fsf@gmail.com> (Robert Pluim's message of "Fri, 05 Feb 2021 10:53:51 +0100") Received-SPF: pass client-ip=198.61.254.31; envelope-from=bounce+ffeceb.97dbd8-emacs-devel=gnu.org@klanderman.net; helo=so254-31.mailgun.net X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:263989 Archived-At: >>>>> On February 5, 2021 Robert Pluim wrote: >>>>> On Thu, 04 Feb 2021 16:14:48 -0500, Greg Klanderman said: >>>>> On February 4, 2021 Robert Pluim wrote: >>>>> On Wed, 03 Feb 2021 16:52:15 -0500, Greg Klanderman said: >>>>> On February 1, 2021 Robert Pluim 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