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

[Eli Zaretskii <eliz@gnu.org>]

> From: Ken Raeburn <raeburn@permabit.com>
> Cc: 11822@debbugs.gnu.org
> Date: Fri, 11 Sep 2015 19:11:30 -0400
> 
> > [redisplay-dont-pause] should avoid redisplaying other frames
> > when input is available after redisplaying the first one.  Your
> > original complaint was (and still is, as far as I'm concerned)
> > that Emacs was unnecessarily trying to redisplay frames on another
> > display, which caused undue network round-trips for communicating
> > with X.  Setting that variable to nil should at most only redraw
> > the selected frame when user input is available.  If you perform
> > this experiment when the frame(s) in need of network
> > communications are on the inactive display, you should see whether
> > the effect is tangible.  If it isn't, trying to refrain from
> > displaying frames on other displays, per one of your suggestions,
> > will not be very effective, perhaps not at all, and we need to
> > look for other ways to optimize this use case.
> 
> Well... if by "redisplay" we include both the face realization and text
> drawing, yes, that's my complaint, but no, I don't think the flag will
> avoid *all* of the redisplay mechanism for frames after the first, only
> the text-drawing part. If we get as far as redrawing text on any of the
> frames, including the selected one, it looks to me like by that point
> we've already updated faces on any frames for which we think we need to,
> and that's the part that makes it slow.

Please look at the code (as it was before what I describe was
deleted): We have a loop over all frames.  Each iteration through the
loop, we first compute the glyph matrices for all the windows on that
frame (by calling redisplay_windows), which includes recalculating all
the faces when we think they changed.  Then we call update_frame for
that frame, which delivers the changes to the glass.  If update_frame
returns non-zero, _we_abort_the_loop_, i.e. we don't proceed doing
anything for the remaining frames.  And update_frame returns non-zero
if it sees input available and redisplay-dont-pause is nil.

Therefore, when input becomes available during displaying the first
frame, at most that one frame should be redrawn, and then Emacs should
abandon redisplay.  It should continue abandoning it for as long as
there's input to process.

At some point, we removed the code that broke out of the frame
displaying loop in that scenario, so now what happens is indeed what
you describe.  We even had a more elaborate code that aborted the loop
based on measuring the time it took to redisplay the first frames; it
was also deleted.

We could reinstate all that, but given that we deleted it several
releases ago, this begs the question how far are we prepared to go for
catering to such rare use cases?

> So I'd expect it to possibly "save" an unnoticeable amount of time
> during which it previously would've sent off text updates to other
> frames without waiting for any X server replies.

Do you still think so, after what I explained above?

> (Also: Iconifying the remote frame doesn't seem to help. In
> prepare_menu_bars, when all_windows is set but some_windows is not, the
> call to x_consider_frame_title, which can trigger face realization, *is*
> called for iconified frames.)

Something else to optimize, I guess.

> > Then these calls cannot be avoided with the current design of face
> > realization.  IOW, creating a single frame where communications with X
> > are over a slow network will always be slow, unless we radically
> > change the design and implementation of faces.
> 
> We can reduce the number of round trips. If we only ever use 13 distinct
> named colors, in an ideal world we could make do with 13 round trips to
> allocate them in the colormap. But then we need an additional level of
> reference counting or garbage collection on the client (Emacs) side.

I said "unless we radically change the design and implementation of
faces".  We must work on our communications skills, because otherwise
I cannot see how what you say contradicts what I said.

> Start with reducing unnecessary frame updates and face cache
> invalidations (reducing the number of face realization calls), and
> redundant color lookups (which could make realizing any single face
> anew faster), and only if that's not enough should we consider more
> complicated stuff like the above.

I will leave the color look up stuff out of the initial attempt to
optimize this use case, primarily because I think it's a separate
step, which logically belongs to changing how faces are realized, and
also because I'd like to see how much of the problem is removed by
that initial attempt.

> >> 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.
> >
> > That should be part of redesigning how faces are realized.  But you
> > rejected the idea, so how do you expect this to happen?
> 
> Let the generic face code continue to process each face independently.
> It doesn't need to know that the X11 layer is providing the information
> out of a cache in "struct x_display_info". Such a cache might also help
> with lookups from image-processing code too.

Patches to the relevant parts of the X display back-end to do this are
welcome.

Thanks.