From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.bugs Subject: bug#11822: 24.1; emacsclient terminal mode captures escape characters as text Date: Thu, 10 Sep 2015 02:59:06 -0400 Message-ID: <6e613irc91.fsf@just-testing.permabit.com> 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> <83si6n65ld.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1441868429 19036 80.91.229.3 (10 Sep 2015 07:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 10 Sep 2015 07:00:29 +0000 (UTC) Cc: 11822@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Sep 10 09:00:17 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 1ZZvq9-0002E1-QB for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 09:00:14 +0200 Original-Received: from localhost ([::1]:47344 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZvq9-0001lm-8k for geb-bug-gnu-emacs@m.gmane.org; Thu, 10 Sep 2015 03:00:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45703) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZvq5-0001kF-6I for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 03:00:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZZvq1-0000ws-Uu for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 03:00:09 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:33979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZZvq1-0000wZ-RX for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 03:00:05 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZZvq1-00087g-3K for bug-gnu-emacs@gnu.org; Thu, 10 Sep 2015 03:00:05 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 10 Sep 2015 07:00:04 +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.144186835431140 (code B ref 11822); Thu, 10 Sep 2015 07:00:04 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 10 Sep 2015 06:59:14 +0000 Original-Received: from localhost ([127.0.0.1]:54422 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZvpB-00086B-Sp for submit@debbugs.gnu.org; Thu, 10 Sep 2015 02:59:14 -0400 Original-Received: from mail-qg0-f49.google.com ([209.85.192.49]:35661) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZZvp8-000862-V0 for 11822@debbugs.gnu.org; Thu, 10 Sep 2015 02:59:11 -0400 Original-Received: by qgt47 with SMTP id 47so28069388qgt.2 for <11822@debbugs.gnu.org>; Wed, 09 Sep 2015 23:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=permabit.com; s=google; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-type; bh=v2cwrNJZ3/ympdhP3ZV8uiabvwyA14WxX443mb7W+Q0=; b=kp/QHbSbvR4uUybIgntzlwCrj7eZEHSvSffFCpNM5l7GUkcSj+oJ9+BRwXkcOX9yK2 3JnBcs3aSHL6+8nr0UExGQBAp93my5H7XmnVLkMH+sWGAGpO30vJZZzLe51oKsZPFsbz Vnj+z33RlNNwMCpdMC5n10SogZWZHYLnvHgw4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-type; bh=v2cwrNJZ3/ympdhP3ZV8uiabvwyA14WxX443mb7W+Q0=; b=bcV2iSHYURgnyv1a5hdbys8WTcRWXV9Za+rkCluVPfuDMcoqiD9aDbZOLCI2UudLOO ypw4Uj7saN0R2LdZfWVOA0CZBuqoye0JQasr+pg/x0RnaoN5I6W/KHXV8tSpQU07L0pF Jzdpofp1DzPAmY6/QYiYDED+l3cy9PJq7pMV13ZgNPitMXGcbdYVVcX7mkqSQDPI3SlA r6yGVjEzOZPjpVph0ce4btEpZ73XduPnBszMMJxq7k4L3oGGHYt4R45/FbAGWOtNCZi/ I2Ugjz7rbZPCoNqLENRhaOUfwAS6PZz5ClapqAqgJIQuRa6P+huyx5+nOW6FNdIdTbmi 0A2A== X-Gm-Message-State: ALoCoQleB3aQ3GlLvW5Y0nGIFL0QUx4zeR7toxJXZAS022RBsRBrUGYBJtGVSJjkntJhtmUx876b X-Received: by 10.140.16.43 with SMTP id 40mr50703566qga.64.1441868350290; Wed, 09 Sep 2015 23:59:10 -0700 (PDT) Original-Received: from just-testing.permabit.com (vpn.permabit.com. [66.202.84.2]) by smtp.gmail.com with ESMTPSA id o25sm5494730qkl.29.2015.09.09.23.59.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Wed, 09 Sep 2015 23:59:08 -0700 (PDT) In-Reply-To: <83si6n65ld.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 09 Sep 2015 17:16:14 +0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.93 (gnu/linux) 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:106336 Archived-At: Eli Zaretskii writes: >> 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? Replies from the X server to LookupColor or AllocColor requests. That's when the round-trip time and the number of round trips become important. If we're just sending text-drawing requests, and if there's enough bandwidth or socket buffer space (neither of which is actually guaranteed), we shouldn't need to wait, and it shouldn't cause any significant delay for updates to other frames. So once the global-variable aspects are addressed, the sort of delay I'm dealing with should only come up for things like changes to colors in faces that are used on multiple displays. > 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. I didn't mean having them seconds or minutes out of date. What I'm thinking of -- assuming for the sake of argument that we're still concerned about types of changes that'll still require changes on multiple frames even after the global-variable issues are addressed, like changing the default face's foreground color -- would be something like updating faces and then content on one frame, then going on to the next and updating faces and then content, but preempting the rest ASAP if user input is received. If recompute_basic_faces is called, since it triggers a lot of round trips, at least one or two possible preemption points in the middle of that sequence. Plus more intelligent ordering of frames for updating (see below). And image handling probably fits in there too somewhere. If there's no input received during the process, or after the input is dealt with, all the face computations and display updates should proceed normally and all frames should become up-to-date. I was thinking in terms of delays or idle timers (e.g., wait for "idle" time of 0.0001s then do this next update increment) as a possible simple and stupid way to implement that, driven by the input-handling part of the program, but reviewing what I'm learning about Emacs redisplay, it doesn't really make sense. >> 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. I tried it in the scratch buffer in a new Emacs process. It doesn't call recompute_basic_faces, but it did call realize_face twice, and XParseColor and x_alloc_nearest_color_1 each four times. So that's eight round trips that seem unnecessary as we should already have the color definitions and allocated color cells. >> 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? Reorder the frame traversal. If in some circumstances a full redisplay process updating multiple frames can be slow (fewer such circumstances after the work Stefan outlined and has started gets done, but I expect some cases will remain), and if user input can preempt completion of redisplay (I see comments indicating it can but don't know precisely how or how well it works with X), which frames do we want updated first or more often? Near as I can tell, it's done by the age of the frame, from newest to oldest, because newer ones are added to Vframe_list at the front. My comments about the current display vs other displays vs tty frames are just ideas of what a better heuristic might look like. If we effectively do face recomputation across all frames needing it as a separate pass before doing screen updates, though, it might not help. (For face updates, at least... I haven't traced through the image handling.) > 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. Yep, that's why they should all get updated ASAP if some input doesn't preempt redisplay. It doesn't argue for order-of-creation processing though. > 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? I haven't. I tried remotely iconifying it via Lisp code, but Emacs still thought it was visible. Now that I'm at home, I'll try to leave it iconified before heading back to work. >> > 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. I think that's the worst part for my new-frame-with-multiple-displays case, but I don't think it's the only area of the code that could be improved. I took a look at the calls to x_alloc_nearest_color_1. In creating an initial frame with "emacs -Q", I get over two hundred calls, and every one requires a round-trip to the server. But there were only 13 distinct RGB color values passed. The most popular values passed were these: 88 x_alloc_nearest_color_1(0000/0000/0000) (white) 71 x_alloc_nearest_color_1(ffff/ffff/ffff) (black) 15 x_alloc_nearest_color_1(bfbf/bfbf/bfbf) (grey75) Then there's XParseColor; over 2300 calls, but only about 9% require round-trips to the server, the rest using the "#RRGGBB" syntax that gets parsed locally. I haven't traced which part of the program accounts for what fraction of the calls. Eliminating unnecessary cache clearing might reduce these, maybe by a factor of two or more, but that's still excessive; and 100 round trips with a 30ms RTT would still contribute 3 seconds to the time needed to finish setting up the initial frame. Now, if instead we had just *one* call to XAllocNamedColor for "white", and one for "black", etc.... Ken