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: Fri, 11 Sep 2015 02:54:06 -0400 Message-ID: <6ezj0tphtd.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> <6e613irc91.fsf@just-testing.permabit.com> <83bnda5lso.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1441954524 7718 80.91.229.3 (11 Sep 2015 06:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Sep 2015 06:55:24 +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 Fri Sep 11 08:55:12 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 1ZaIEp-0006jy-H6 for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Sep 2015 08:55:11 +0200 Original-Received: from localhost ([::1]:54467 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaIEo-0001bm-HZ for geb-bug-gnu-emacs@m.gmane.org; Fri, 11 Sep 2015 02:55:10 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58079) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaIEj-0001Yb-Pp for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 02:55:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZaIEg-00035V-Gl for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 02:55:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:35627) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZaIEg-00035H-Cy for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 02:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1ZaIEg-0005MK-1b for bug-gnu-emacs@gnu.org; Fri, 11 Sep 2015 02:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Ken Raeburn Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Sep 2015 06:55: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.144195445320539 (code B ref 11822); Fri, 11 Sep 2015 06:55:01 +0000 Original-Received: (at 11822) by debbugs.gnu.org; 11 Sep 2015 06:54:13 +0000 Original-Received: from localhost ([127.0.0.1]:56070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaIDs-0005LC-EM for submit@debbugs.gnu.org; Fri, 11 Sep 2015 02:54:13 -0400 Original-Received: from mail-qg0-f45.google.com ([209.85.192.45]:34130) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1ZaIDq-0005L3-10 for 11822@debbugs.gnu.org; Fri, 11 Sep 2015 02:54:11 -0400 Original-Received: by qgez77 with SMTP id z77so55683558qge.1 for <11822@debbugs.gnu.org>; Thu, 10 Sep 2015 23:54:09 -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:content-transfer-encoding; bh=d9UJ2oAdJLtvXmfMcYpUSfqqc7CKsfNjvdUMFuW4vmg=; b=KHG/yJ3mlqhRAOLxt+Pn7OAdnWLR78X7y8k/f6gXE7gGEmDRC95L1m4qUhOHVLmkdw 7M3Nly7R8DX4wXXQmNlBCa/i7PnyeJ7LcMcKR0DFRJT6idua+uXkKuMWh2fMVNgCiieK RcI0u5eDiPwHvJAMni4XlQL7beX3BuSbalqVg= 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 :content-transfer-encoding; bh=d9UJ2oAdJLtvXmfMcYpUSfqqc7CKsfNjvdUMFuW4vmg=; b=GnbUIW1qe2lcEbML/RHCI8OK9Gcf4BWbiCVBC1Fdby2DW04MV+2azHEX+t2AIhso5N gQgoGkoCzLwtsIAentJBV+HiLhSXmAh2hDsxGiPTGUlZ9XnkB7cYWkb7x8OeEgKAAYi9 eIk+xHRdMZKSu4oD5Hnl2OxVutyHQlXrmEdTN9eUvTMZhwMTQWXEAROSDOwNIC239JSw WS6jQLReE3UV0RZmfG7yIlNHKp0wJwhGpmdLYG5y8Zk2hlNk9bwv6LmSdHC0EKk5rlRq j3/xVShauBbwacm9PsjVoJR7uoHJkV3R4Nb8jGZhnqtEmbXNRBLr8U+7wcTqHDSkYuA4 207w== X-Gm-Message-State: ALoCoQmHPJoKu4IFDktYORYFMZ3v43L1/A20E2mT73d4iIw8FLudeMuo8iHM8fClAwsQsekQSzfw X-Received: by 10.140.231.211 with SMTP id b202mr64191874qhc.83.1441954449398; Thu, 10 Sep 2015 23:54:09 -0700 (PDT) Original-Received: from just-testing.permabit.com (vpn.permabit.com. [66.202.84.2]) by smtp.gmail.com with ESMTPSA id 88sm45842qkr.5.2015.09.10.23.54.07 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Thu, 10 Sep 2015 23:54:07 -0700 (PDT) In-Reply-To: <83bnda5lso.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 10 Sep 2015 18:36:07 +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:106395 Archived-At: Eli Zaretskii writes: >> [...preempting redisplay...] > We had this ability in the past, but we all but deleted it, as it > seemed not to make redisplay more responsive. [...] > But it could be that we didn't look at the effect of this when frames > are displayed via X over slow networks. So please try experimenting > with an Emacs before the deletion (I think 24.4 is old enough), and > see if setting redisplay-dont-pause to nil helps in your case. If it > doesn't, then what you suggest above is probably not an idea that will > yield tangible benefits. Interesting. Hmm... looking at the code (24.3.93 is what I have handy), it looks like update_frame is the interesting point where this is checked, which is called from redisplay_internal after the point where prepare_menu_bars currently triggers recompute_basic_faces calls across the frames. So if I understand this right, enabling this preemption (setting redisplay-dont-pause to nil) would let new user input preempt redisplay of some frames, but only after prepare_menu_bars has already caused the color-related round-trips to happen. That seems to be the slow part, so I'm not sure what I should expect to see happen differently. >> >> 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. >>=20 >> 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. > > For how many frames were XParseColor and x_alloc_nearest_color_1 > called? If only for the single frame where you've changed the face, > then it's expected. In that test I had only one frame. If I create a second frame also showing *scratch* and shrink the text size, both frames need updating, and I do see twice as many calls. If I create a second frame, load a text file into one frame, with no font-lock highlighting, and shrink the text size for the text file, I see two pairs of calls (one for white, one for black). Those are as I'd expect -- once per frame showing that buffer, and only for the faces affected. So it's only a smaller waste of time, but the calls are still redundant with information we've already retrieved. I've read that a tenth of a second is a good rough threshold on response time between the user feeling that the program is responding immediately and feeling that it isn't. With a RTT of 30ms, four round trips will exceed that. > > If you are suggesting to be more selective wrt what exactly needs to > be recomputed during face update, then this will need some analysis > regarding which parts are more expensive than others, and introduction > of corresponding flags to signal which face aspects need to be > recomputed. Assuming this is even possible without a more or less > complete rewrite of face-related code (which currently just throws > away a face and realizes it anew), the relative cost (in terms of > time) of recomputing each aspects will most probably be different for > different display back-ends, perhaps even for different network > bandwidths. Someone=E2=84=A2 should do this research and publish the res= ults, > before we could start designing a good solution. I don't think I'd try anything that fancy. Realizing faces from scratch is probably fine as long as that can be made fast enough in most reasonable cases. >> > Given this general description, what would "lower priority" mean in >> > practice? >>=20 >> Reorder the frame traversal. > > Since the goal is to limit redisplay to a single frame, the current > one, I think this is a moot point. Limiting redisplay to one frame when possible will go a long way. There will still be cases that need to update multiple frames (like changing faces used on multiple frames), but they may be infrequent enough that we don't need to worry about it. >> > 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. >>=20 >> 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. > > We should see about that once the global face recalculation is gone. > >> 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: >>=20 >> 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) >>=20 >> 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. > > Once again, it is necessary to figure out which portions of these > calls is on behalf of frames other than the one being created. Those > calls should all but go away after the global effect of face updating > is eliminated. Only after that we will see how much of this problem > remains. In case I wasn't clear, the numbers above were for creating the initial frame; there was no other to act on behalf of. Emacs startup and handling of the initial frame may be special in some ways compared to creating additional frames once Emacs is up and running, but the startup speed contributes to the user experience too. I know I'm sort of jumping around between use cases here, but different use cases are impacted differently by different aspects of the network handling here. I've hit other cases that don't involve multiple frames. Tooltip window popups involves way too many round trips, and highlighting and un-highlighting parts of the mode line as the mouse is moved through it can sometimes (not sure what the circumstances are) trigger color queries on every change. >> Eliminating unnecessary cache clearing might reduce these, maybe by a >> factor of two or more, but that's still excessive > > What is the estimation of "factor of two or more" is based on? Why > not by an order of magnitude, for example? My email a few days ago with the gdb stack traces showed three expensive calls to recompute_basic_faces (plus three very cheap ones) in setting up the initial frame. If that's caused by needlessly deciding twice that we have to recompute faces we've already computed for the one and only frame, and that those cases can be identified and fixed, that would presumably eliminate two of the three sets of LookupColor and AllocColor requests being issued because of recompute_basic_faces. There are additional requests coming via other paths (e.g., setting mouse color), so I don't think we'd get a full factor of three unless they're affected in exactly the same way. Though, it's possible they could be worse offenders, too. Three might be a better estimate than two, but I would be very surprised (but pleased) to get much more than that this way. There's no other frame at this point for there to be queries generated for, so any code changes from "recompute on all frames" to "recompute on the current frame" probably won't change this. I was also thinking of the round-trips involved in the image (tool-bar icon) handling, where x_disable_image caused a lot of round trips, but that's not actually XParseColor and XAllocColor, it's XQueryColors, and I haven't looked at whether there's redundant work there. Given that there were nearly 100 round trips, I hope there is, since then we might be able to eliminate some of them. > >> Now, if instead we had just *one* call to XAllocNamedColor for >> "white", and one for "black", etc.... > > Why do you think we will have more than that? The color lookups are currently done for each face independently. If multiple faces use the same colors, we'll have multiple requests to the X server for those colors. Consider: 15 faces times at least 2 colors per face (foreground and background, plus maybe box, underline, overline, and strike-through), times 2 round trips per color (LookupColor, assuming not a hex RGB value, and AllocColor), is at least 60 round trips. At 30 ms per round trip that's 1.8 seconds. Using XAllocNamedColor instead of XParseColor+XAllocColor would cut that in half, but it would still be very noticeable. Ken