bug#11822: 24.1; emacsclient terminal mode captures escape characters as text

[Ken Raeburn <raeburn@permabit.com>]

> 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