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: Thu, 10 Sep 2015 02:59:06 -0400
> 
> > 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.
> 
> I didn't mean having them seconds or minutes out of date. What I'm
> thinking of -- assuming for the sake of argument that we're still
> concerned about types of changes that'll still require changes on
> multiple frames even after the global-variable issues are addressed,
> like changing the default face's foreground color -- would be something
> like updating faces and then content on one frame, then going on to the
> next and updating faces and then content, but preempting the rest ASAP
> if user input is received. If recompute_basic_faces is called, since it
> triggers a lot of round trips, at least one or two possible preemption
> points in the middle of that sequence.

We had this ability in the past, but we all but deleted it, as it
seemed not to make redisplay more responsive.  The comment which was
left when this was done says:

  /* Contrary to expectations, a value of "false" can be detrimental to
     responsiveness since aborting a redisplay throws away some of the
     work already performed.  It's usually more efficient (and gives
     more prompt feedback to the user) to let the redisplay terminate,
     and just completely skip the next command's redisplay (which is
     done regardless of this setting if there's pending input at the
     beginning of the next redisplay).  */

But it could be that we didn't look at the effect of this when frames
are displayed via X over slow networks.  So please try experimenting
with an Emacs before the deletion (I think 24.4 is old enough), and
see if setting redisplay-dont-pause to nil helps in your case.  If it
doesn't, then what you suggest above is probably not an idea that will
yield tangible benefits.

> >> 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.
> 
> I tried it in the scratch buffer in a new Emacs process. It doesn't call
> recompute_basic_faces, but it did call realize_face twice, and
> XParseColor and x_alloc_nearest_color_1 each four times. So that's eight
> round trips that seem unnecessary as we should already have the color
> definitions and allocated color cells.

For how many frames were XParseColor and x_alloc_nearest_color_1
called?  If only for the single frame where you've changed the face,
then it's expected.

If you are suggesting to be more selective wrt what exactly needs to
be recomputed during face update, then this will need some analysis
regarding which parts are more expensive than others, and introduction
of corresponding flags to signal which face aspects need to be
recomputed.  Assuming this is even possible without a more or less
complete rewrite of face-related code (which currently just throws
away a face and realizes it anew), the relative cost (in terms of
time) of recomputing each aspects will most probably be different for
different display back-ends, perhaps even for different network
bandwidths.  Someone™ should do this research and publish the results,
before we could start designing a good solution.

> > Given this general description, what would "lower priority" mean in
> > practice?
> 
> Reorder the frame traversal.

Since the goal is to limit redisplay to a single frame, the current
one, I think this is a moot point.

> > 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.
> 
> I think that's the worst part for my new-frame-with-multiple-displays
> case, but I don't think it's the only area of the code that could be
> improved.

We should see about that once the global face recalculation is gone.

> I took a look at the calls to x_alloc_nearest_color_1. In creating an
> initial frame with "emacs -Q", I get over two hundred calls, and every
> one requires a round-trip to the server. But there were only 13 distinct
> RGB color values passed. The most popular values passed were these:
> 
>      88 x_alloc_nearest_color_1(0000/0000/0000) (white)
>      71 x_alloc_nearest_color_1(ffff/ffff/ffff) (black)
>      15 x_alloc_nearest_color_1(bfbf/bfbf/bfbf) (grey75)
> 
> Then there's XParseColor; over 2300 calls, but only about 9% require
> round-trips to the server, the rest using the "#RRGGBB" syntax that gets
> parsed locally. I haven't traced which part of the program accounts for
> what fraction of the calls.

Once again, it is necessary to figure out which portions of these
calls is on behalf of frames other than the one being created.  Those
calls should all but go away after the global effect of face updating
is eliminated.  Only after that we will see how much of this problem
remains.

> Eliminating unnecessary cache clearing might reduce these, maybe by a
> factor of two or more, but that's still excessive

What is the estimation of "factor of two or more" is based on?  Why
not by an order of magnitude, for example?

> Now, if instead we had just *one* call to XAllocNamedColor for
> "white", and one for "black", etc....

Why do you think we will have more than that?