From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Wed, 09 Sep 2015 17:16:14 +0300 Message-ID: <83si6n65ld.fsf@gnu.org> References: <6eipe9fypj.fsf@just-testing.permabit.com> <83d34h739a.fsf@gnu.org> <501848BE.10702@permabit.com> <5021D940.8050401@permabit.com> <415962DC-9BF5-4595-8180-7BE8DB545206@permabit.com> <502427D2.3080003@permabit.com> <83ipcre0fm.fsf@gnu.org> <2AB38709-2307-437E-A242-70B8A358BE4F@permabit.com> <83a9y3dwa8.fsf@gnu.org> <838vdndv9m.fsf@gnu.org> <1341183F-84AB-4257-B28B-57BDE5CA4F20@permabit.com> <83r3m97bzs.fsf@gnu.org> <37C523EE-3D76-40F7-B7B2-99D6F0BD7B97@permabit.com> <83bndc7r5b.fsf@gnu.org> <6ea8swr8ja.fsf@just-testing.permabit.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1441808274 13639 80.91.229.3 (9 Sep 2015 14:17:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Sep 2015 14:17:54 +0000 (UTC) Cc: 11822@debbugs.gnu.org To: Ken Raeburn Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 09 16:17:42 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZZgBo-000117-QX for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Sep 2015 16:17:33 +0200 Original-Received: from localhost ([::1]:43061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZgBo-0006D6-8g for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Sep 2015 10:17:32 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35866) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZgBP-0005bZ-8Z for bug-gnu-emacs@gnu.org; Wed, 09 Sep 2015 10:17:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZgBK-0001Hz-8o for bug-gnu-emacs@gnu.org; Wed, 09 Sep 2015 10:17:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33416) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZgBK-0001Hv-4q for bug-gnu-emacs@gnu.org; Wed, 09 Sep 2015 10:17:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZgBJ-0004NV-QL for bug-gnu-emacs@gnu.org; Wed, 09 Sep 2015 10:17:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Sep 2015 14:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 11822 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 11822-submit@debbugs.gnu.org id=B11822.144180818216778 (code B ref 11822); Wed, 09 Sep 2015 14:17:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 9 Sep 2015 14:16:22 +0000 Original-Received: from localhost ([127.0.0.1]:53859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZgAf-0004MX-LS for submit@debbugs.gnu.org; Wed, 09 Sep 2015 10:16:22 -0400 Original-Received: from mtaout27.012.net.il ([80.179.55.183]:49423) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZgAc-0004MO-Nd for 11822@debbugs.gnu.org; Wed, 09 Sep 2015 10:16:19 -0400 Original-Received: from conversion-daemon.mtaout27.012.net.il by mtaout27.012.net.il (HyperSendmail v2007.08) id <0NUE00800Y268P00@mtaout27.012.net.il> for 11822@debbugs.gnu.org; Wed, 09 Sep 2015 17:12:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([84.94.185.246]) by mtaout27.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NUE00LFQY5JSMB0@mtaout27.012.net.il>; Wed, 09 Sep 2015 17:12:56 +0300 (IDT) In-reply-to: <6ea8swr8ja.fsf@just-testing.permabit.com> X-012-Sender: halo1@inter.net.il X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:106296 Archived-At: > From: Ken Raeburn > Cc: 11822@debbugs.gnu.org > Date: Tue, 08 Sep 2015 15:54:49 -0400 > > > I'm still not following you: what do input events have to do with the > > need to redisplay or not redisplay some frame(s)? > > If we don't need to update a frame, that's great. But I'm also thinking > about cases where a frame does need updating but isn't on the > currently-used display. Though for it to be important in this context, > updating text probably don't matter much(?), just cases where we > actually need to stop and wait for a reply, which probably means changes > to face definitions like updating the foreground color. I don't follow: what replies did you have in mind? Replies from whom or what? Emacs redraws windows on frames that require redrawing because something happened that affects how the visible portion of the windows look on the glass. Emacs doesn't consider some changes more important than others, nor waits for any replies, when it decides that changes to buffers or strings require redisplay of some window. I don't think the idea of holding off some display updates for whatever reasons will fly, because users rightfully expect the display to be up to date, unless Emacs is busy computing something. > Would changing sizes for a face cause the face to be recomputed from > scratch? It doesn't in my testing (I tried "C-x C-+"). You can easily try that yourself: put a breakpoint on recompute_basic_faces, and see if it breaks when you change the face size. > Giving updates to a remote display that's not the currently-active one > lower priority than dealing with input on the active display could let > us be more responsive on the active display, but at the risk of leaving > the other display slightly out of date in occasional cases where it > might matter (a second person working at the second display at the same > time, both displays mapping to the same physical display via multiple > ssh connections, etc). I'm not sure I understand the practical meaning of "lower priority". When the display engine decides that more than one window needs to be redisplayed, it iterates through all the frames, one by one, and on each frame iterates through all of its windows. The order of the frame traversal is independent of their displays, and it is sequential. Given this general description, what would "lower priority" mean in practice? And anyway, I don't think we should do anything that could produce frames that are not up to date, because we will be crucified by users. I can easily envision a use case where frames on the currently-inactive display are actively watched by a user, perhaps even the same user who types at the currently-active display. We can justify partially outdated display when Emacs has something to do, but we cannot justify that when Emacs is idle. However, Emacs should refrain from redrawing iconified frames, so one possible method of saving some time should be to leave frames on the inactive display iconified. Did you try that, and if so, did that help? > > Anyway, I think preventing frames from being unnecessarily redisplayed > > will bring larger benefits than just avoiding realization of some > > faces. > > Perhaps so. I think we've got inefficiencies at multiple levels: > updating frames that don't need it; updating faces that don't need it > (on frames where something does or may need updating); redundant color > queries to a display; probably some issues around image handling. Fixing > any of them would be an improvement, but addressing more than one is > probably better still. My reading of the discussion and your backtraces indicate that all of that stems from a single problem: when we create or update faces, we set a global flag that causes faces to be recomputed on all frames. This then snowballs into the need to reload colors and redraw all frames. So the actual inefficiency, according to my analysis, is just one: we are too conservative in the effect that is caused by a change in faces. We should limit that effect to the frame whose faces are being changed. This should eliminate at least some of the unnecessary X requests, hopefully a lot of them. (I say "hopefully" because some of the face changes are global, i.e. are intended to affect all the frames, and for those we won't be able to avoid recomputing faces on all the frames and then redrawing them all.)