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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

> 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.

> 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).

> 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.

> 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.

Thanks.