Re: Redisplay problems?

[martin rudalics <rudalics@gmx.at>]

 > 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