Re: Redisplay problems?

[martin rudalics]

> Yes, tho I'm not sure I agree with "subsumes": according to the comment,
> setting more things "garbaged" may cause some frame's content to stay
> blank for a while (because Emacs is in the middle of something which
> prevents redisplay from taking place).

OK.  But the major issue is to prevent a frame's contents to stay blank
forever (unless the user intervenes in some way or the other).

> And of course, the frame's "garbaged" bit may not always be needed: if
> the frame was simply iconified+deiconified without any other change,
> there's no need to recompute matrices nor redraw anything, since it's
> pretty much the same as obscuring the frame with another and then
> exposing it again.

Yes, that's the main difference.  But it requires to carefully keep
track of changes via the `garbaged' slot.

> I'm not 100% clear either, but my current understanding is that
> "garbaged" means that the frame needs to be fully redrawn

... where "fully" means all windows?

> in the
> following sense:
>
> Normal redisplay takes place by first computing new matrices, then
> comparing the old matrices to the new matrices to discover what needs to
> be changed on screen, then redrawing the parts that have changed.
>
> So "garbaged" means that we should not try to only redraw the parts that
                                     ^^^

> have changed.

I'm not sure I follow you here.  If we do a resize of the frame we may
need larger matrices so we tell the display engine via the resized_p
slot.  If a change is restricted to a certain buffer or window only, we
can tell the display engien which one is affected.  Other from that what
kind of guidance can you possibly give to the display engine?

> Note that the drawing that takes place in response to Expose events is
> not a "redraw": "redraw" is when a change inside Emacs causes a need to
> change the display, whereas expose events are due to changes outside
> of Emacs.

But it's a redraw when we expose a hitherto invisible/obscured frame
whose contents have changed while it was invisible/obscured.

> Part of the reason it's still fuzzy is that xdisp.c seems to recompute
> the matrices when it finds a "garbaged" frame,

But we do have to compute the new matrices to know whether they have
changed.  I'm fully confused now.

> so it seems that it
> doesn't just cause it to "redraw".  I have the impression that this is
> a mistake in that it's more work than needed, and also in that some code
> relies on that behavior (i.e. it sets the bit to cause a complete
> redisplay+redraw).

What is the "less work" that's needed?

martin