Re: Redisplay problems?

[Eli Zaretskii <eliz@gnu.org>]

> From: Stefan <monnier@IRO.UMontreal.CA>
> Cc: rudalics@gmx.at, christian@defun.dk, kanru@kanru.info, cloos@jhcloos.com,
>         emacs-devel@gnu.org
> Date: Mon, 24 Mar 2014 08:33:30 -0400
> 
> > I still don't see anything performance critical even in this scenario.
> 
> I lived with the older slower behavior for many years, indeed.
> 
> But computers aren't getting very much faster and avoiding a rebuild of
> the glyph matrices sped up some of my use cases significantly, making
> the behavior noticeably smoother.

On these general terms, we are in violent agreement.  (Btw, what about
parallel redisplaying of several frames by several independent
threads?)

However, what I wrote was only about deiconifying a frame, or
redrawing a frame which was entirely obscured.  If we are still
talking about that case, please tell more about the situations where
deiconifying a frame was a bottleneck or even a significant annoyance.

In any case, I'm not opposed to attempts to optimize these scenarios.
How to do that is another question.  Blindly assuming that the current
matrices are up to date doesn't sound like a good idea to me: we will
momentarily flash incorrect display, and sooner or later people will
complain.  And such an incorrect redisplay will be immediately
followed another one, so what exactly have we gained?  But we could do
this when the redisplay flag of the frame is not set, for example.

If the redisplay flag of an obscured/iconified frame _is_ set, then it
looks like you cannot win anyway, because the entire frame needs to be
completely redisplayed, and comparing against the current matrices is
meaningless (since nothing is on the glass, so a full redraw is the
only alternative).  So I think setting the garbaged flag in this case
is TRT.

IOW, the garbaged flag of an obscured or iconified frame should only
be set after its redisplay flag is set.  I don't see any place for
further optimization; do you?