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

[Eli Zaretskii]

> From: Ken Raeburn <raeburn@permabit.com>
> Cc: 11822@debbugs.gnu.org
> Date: Tue, 08 Sep 2015 15:54:49 -0400
> 
> > I'm still not following you: what do input events have to do with the
> > need to redisplay or not redisplay some frame(s)?
> 
> If we don't need to update a frame, that's great. But I'm also thinking
> about cases where a frame does need updating but isn't on the
> currently-used display. Though for it to be important in this context,
> updating text probably don't matter much(?), just cases where we
> actually need to stop and wait for a reply, which probably means changes
> to face definitions like updating the foreground color.

I don't follow: what replies did you have in mind?  Replies from whom
or what?

Emacs redraws windows on frames that require redrawing because
something happened that affects how the visible portion of the windows
look on the glass.  Emacs doesn't consider some changes more important
than others, nor waits for any replies, when it decides that changes
to buffers or strings require redisplay of some window.

I don't think the idea of holding off some display updates for
whatever reasons will fly, because users rightfully expect the display
to be up to date, unless Emacs is busy computing something.

> Would changing sizes for a face cause the face to be recomputed from
> scratch?

It doesn't in my testing (I tried "C-x C-+").  You can easily try that
yourself: put a breakpoint on recompute_basic_faces, and see if it
breaks when you change the face size.

> Giving updates to a remote display that's not the currently-active one
> lower priority than dealing with input on the active display could let
> us be more responsive on the active display, but at the risk of leaving
> the other display slightly out of date in occasional cases where it
> might matter (a second person working at the second display at the same
> time, both displays mapping to the same physical display via multiple
> ssh connections, etc).

I'm not sure I understand the practical meaning of "lower priority".
When the display engine decides that more than one window needs to be
redisplayed, it iterates through all the frames, one by one, and on
each frame iterates through all of its windows.  The order of the
frame traversal is independent of their displays, and it is
sequential.

Given this general description, what would "lower priority" mean in
practice?

And anyway, I don't think we should do anything that could produce
frames that are not up to date, because we will be crucified by users.
I can easily envision a use case where frames on the
currently-inactive display are actively watched by a user, perhaps
even the same user who types at the currently-active display.

We can justify partially outdated display when Emacs has something to
do, but we cannot justify that when Emacs is idle.

However, Emacs should refrain from redrawing iconified frames, so one
possible method of saving some time should be to leave frames on the
inactive display iconified.  Did you try that, and if so, did that
help?

> > Anyway, I think preventing frames from being unnecessarily redisplayed
> > will bring larger benefits than just avoiding realization of some
> > faces.
> 
> Perhaps so. I think we've got inefficiencies at multiple levels:
> updating frames that don't need it; updating faces that don't need it
> (on frames where something does or may need updating); redundant color
> queries to a display; probably some issues around image handling. Fixing
> any of them would be an improvement, but addressing more than one is
> probably better still.

My reading of the discussion and your backtraces indicate that all of
that stems from a single problem: when we create or update faces, we
set a global flag that causes faces to be recomputed on all frames.
This then snowballs into the need to reload colors and redraw all
frames.

So the actual inefficiency, according to my analysis, is just one: we
are too conservative in the effect that is caused by a change in
faces.  We should limit that effect to the frame whose faces are being
changed.  This should eliminate at least some of the unnecessary X
requests, hopefully a lot of them.  (I say "hopefully" because some of
the face changes are global, i.e. are intended to affect all the
frames, and for those we won't be able to avoid recomputing faces on
all the frames and then redrawing them all.)