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

[Ken Raeburn <raeburn@permabit.com>]

> Maybe instead of doing
> 
>  prepare_menu_bars:
>    (forall frames (compute-title-and-stuff))
>  later:
>    (forall frames (recompute-glyph-matrices-and-then-display))
> 
> we should do
> 
>  (forall frames
>    (compute-title-and-stuff)
>    (recompute-glyph-matrices-and-then-display))

I think that would probably help, yes.

> BTW, IIUC while Xlib is not designed for [pipelining requests we need to
> receive responses for], the newer Xcb library
> exposes the underlying wire protocol more directly, making it possible
> to send several color requests before waiting for the replies.

That’s good news. Taking full advantage of it would probably require changes to the generic face code, if we want to send all the color names for multiple faces and then wait to collect the responses. But on a smaller scale, doing it for all colors used in defining one face would be a start.

> FWIW, I've used 8bit-deep framebuffers not that long ago.
> But they're probably rare by now, indeed.

So we should probably still support them, I expect. But it may be worth optimizing for the more common case; for example, we could try allocating new colors as they’re requested, when they’re not cached, and if we fail to allocate, then maybe we go clean out the cache of colors no longer in use. (Or after a timeout of several seconds of idle time or something like that, to help us play nicer with the neighbors.)

> As mentioned earlier, I think this is not true if we repeat it per-frame
> since we can have 100 frames, at which point the delay can become
> significant even locally.

Yes. I expect the work you’ve started should help a great deal in that area.

Ken