Re: Excessive redisplay from lots of process output

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Fri, 24 Feb 2023 15:33:52 -0500
> Cc: emacs-devel@gnu.org,
>   azeng@janestreet.com
> 
> On Fri, Feb 24, 2023 at 3:19 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > > From: Spencer Baugh <sbaugh@janestreet.com>
> > > Date: Fri, 24 Feb 2023 15:08:17 -0500
> > > Cc: emacs-devel@gnu.org,
> > >   azeng@janestreet.com
> > >
> > > > This is normal.
> > >
> > > Just to make sure I understand, you said earlier:
> > >
> > > >There are many variables and flags Emacs uses to decide when something
> > > >changed that needs the display to be updated.  Those should generally
> > > >prevent Emacs from running the expensive parts of redisplay if they
> > > >are unnecessary.  The question is why this doesn't work in your case.
> > >
> > > Are you saying this does not apply in the case of reading from
> > > process output? That after reading process output, we always do
> > > an expensive redisplay?
> >
> > Whether redisplay is expensive or not depends on many factors.  But we
> > always flush the frame in that case, yes.
> 
> Why? It seems unnecessary if nothing has changed.

I'm not sure we know that nothing has changed.  I'm also not sure I
understand why XFlush is so expensive when nothing or almost nothing
has changed on display.  Maybe Po Lu could comment.

> > AFAIU, what is problematic for you is the X traffic causes by XFlush.
> 
> I think that is problematic for anyone running with a slow X server; it
> gives the X server a lot to process.

Are you sure?  What exactly does XFlush send to the X server if
nothing was changed on display?

> In other words, I think XFlush should be considered "expensive" and
> avoided where possible.

If that is possible, I agree.