Re: Redisplay problems?

[Stefan]

> (Btw, what about parallel redisplaying of several frames by several
> independent threads?)

Patch welcome.

> 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.

Occasionally, closing a large frame that obscured a dozen frames
underneath could be such a problem, but since in X11 we don't optimize
"obscured" like we do under w32 I haven't noticed it.
In any case, Emacs can't tell the difference between "switching
workspace" and "deiconifying", AFAIK.

> 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?

In case the next redisplay is far away, it's better to display the old
window's content than to leave "garbage" on the screen, I think.
I don't think it's a very serious issue either way.

But the code had a comment specifically mentioning that we preferred
not setting the `garbaged' flag (when possible) so as to avoid
a blank/undraw frame being displayed if a frame is deiconified while
we're in the middle of a toolkit menu.

> But we could do this when the redisplay flag of the frame is not set,
> for example.

We could, yes.  But I'm not sure it would really be better.

> 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.

No: setting the garbaged flag has the side-effect of disabling all
optimizations while computing the new matrices.  And in this case, we
don't need to disable those optimizations, AFAIK.


        Stefan