[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#11822: 24.1; emacsclient terminal mode captures escape characters as
From: |
Ken Raeburn |
Subject: |
bug#11822: 24.1; emacsclient terminal mode captures escape characters as text |
Date: |
Tue, 8 Sep 2015 06:15:47 -0400 |
> On Sep 8, 2015, at 00:48, Eli Zaretskii <eliz@gnu.org> wrote:
>
>> From: Ken Raeburn <raeburn@permabit.com>
>> Date: Mon, 7 Sep 2015 17:09:23 -0400
>>
>> After dropping the ball on this about three years ago, I’ve started digging
>> into it again with version 24.5.
>
> Thanks for the footwork and the data. I will study it and see what I
> can come up with. For now, just a couple of quick comments:
>
>> 1) For a new frame, I doubt any cache clearing is needed when setting
>> screenGamma or other frame parameters; if there’s anything cached before
>> we’ve finished computing the parameters, we may have computed the cached
>> thing too early.
>
> The face cache of a new frame should start out empty, so clearing it
> is a no-op. But maybe you mean something else, I didn't yet have a
> good look at the backtraces.
Since there’s nothing to clear out on that frame, there should be no need to
make the call. But we make it, and the call we make forces the clearing of all
caches, not just the one for that frame.
>> 2) When changing screenGamma or another frame parameter does require
>> clearing some cached values that were based on the old parameter settings,
>> it still shouldn’t affect other frames.
>
> The face cache is per-frame, so indeed, there should be no effect on
> other frames. If the backtraces indicate otherwise, I'd be surprised.
Unfortunately Fclear_face_cache (and global variables like face_change_count or
windows_or_buffers_changed) isn’t frame-specific. So — I expect but haven’t
tested — changing screenGamma on an existing frame will probably also force
faces to be recomputed on every frame.
>
>> 3) When frames on the same display have the same relevant frame parameters,
>> as I expect is by far the most common case, can we share info between them,
>> so these lookups and delays will be per-display instead of per-frame?
>
> Faces are per frame, so it's hard to share them without a lot of
> management code (which would be needed to maintain the illusion of
> frame-specific face definitions).
Yeah, I imagine it would take some work… A cache of X11 color info could
probably be buried in the X-specific display info structure though; that could
probably be more localized in terms of code changes, and probably a piece I can
bite off without a much deeper understanding of redisplay than I have so far.
>
>> 4) If something else (changing a face attribute?) requires potentially
>> updating all frames, maybe we can immediately do just the current frame, or
>> the visible frames on the current display (and maybe tty frames?), and delay
>> updates to other frames/displays briefly — say until an idle timer expires
>> or the frame receives input, whichever happens first — so that we can give
>> priority to user interaction on the selected frame/display?
>
> We should have optimizations in the redisplay code that don't
> redisplay all frames just because faces on one particular frame need
> to be recomputed.
>
> There's a tricky part about this: the display engine is prepared to be
> called for a frame or window that only potentially need redisplay.
> For starters, it should be clear that deciding which frames need
> redisplay involves iterating through all the frames, checking for some
> telltale signs. It just could be (I didn't yet look at your data)
> that some of this iteration somehow calls init_iterator, for the
> purposes of testing whether a frame needs redisplay.
>
> IOW, I think redisplay optimizations don't assume that just
> recomputing the basic faces could be a bottleneck, so it's possible
> that we don't try too hard to avoid that.
I think that’s probably true, and if most people are using local displays most
of the time, they may not be much of a bottleneck. I did a couple experiments
with a local X server and got about half a millisecond round-trip time to the
server to answer some queries. Even multiplying by 160 queries, that’s still
under a tenth of a second of wasted time (though I think there are other wasted
round-trips in the color queries too). I think you’d have to get off the local
network neighborhood to even notice; maybe in such cases people just chalk it
up to slow networks, when actually Emacs could be doing better.
>> 5) Even better, can we do the other-display updates in small increments, so
>> that once we start doing those updates we don’t have a block of 160*RTT
>> seconds where we’re unresponsive to new user input?
>
> Not sure I understand the idea; please elaborate about the increments
> you had in mind.
In realize_basic_faces we call realize_named_face 14 times and
realize_default_face once. For a display that’s not the one the user appears to
be using (selected frame is elsewhere, no X events received), I’m wondering if
we can have Emacs check for events (user input on any frame, subprocess output,
etc), if there are none, realize one face, check for events again, etc., and
when all of the faces are done, do any needed updates to the frame. Give
priority to user interaction as much as possible, both in terms of handling
input events and prioritizing updates to certain frames over others. Of course,
if we get events associated with that other frame/display, or a call is made to
force redisplay, we’d want to get things updated right away.
That’s probably a lot of work. :-) But maybe there are some smaller changes
that could be made. Do we have to realize all 15 right away? If it’s not the
selected frame, perhaps it doesn’t need the (active) mode line face, and if
there are no tool bar or scroll bars, it doesn’t need those faces either. Maybe
they could be processed later as (or if) needed?
I do see some references to the possibility of the colormap filling up. I don’t
know if that’s a real concern on modern platforms (vs X10/early X11 servers),
but I suppose that might be one reason for ensuring that a standard set of
faces get processed before any others….
Ken
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/07
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text,
Ken Raeburn <=
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Stefan Monnier, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/08
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/09
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Ken Raeburn, 2015/09/10
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/10
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Stefan Monnier, 2015/09/10
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/10
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Stefan Monnier, 2015/09/11
- bug#11822: 24.1; emacsclient terminal mode captures escape characters as text, Eli Zaretskii, 2015/09/11