Re: Redisplay problems?

[Stefan]

>> I think my patch indeed fixes this problem by distinguishing between
>> f->garbaged (which presumably stops redrawing in Expose, tho I don't
>> offhand see where that happens) and frame_garbaged (which is needed to
>> get the next redisplay to be properly triggered and performed).
> IIUC my earlier proposal to SET_FRAME_GARBAGED unconditionally subsumes
> what you propose here because I set frame_garbaged and the garbaged slot
> of the frame that received the MapNotify event.  However, since I set
> the garbaged slot unconditionally, your proposal provides a better check
> as to whether we previously have set a frame's garbaged slot correctly.
> Is that observation correct or am I missing something?

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

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.

>> If it looks right, then we might reconsider the SET_FRAME_GARBAGED in
>> w32term.c in light of such a change, but that's even further away from
>> my expertise.
> I'm still struggling with the semantics of what a "garbaged frame" is
> and whether we always set the garbaged slot correctly.

I'm not 100% clear either, but my current understanding is that
"garbaged" means that the frame needs to be fully redrawn 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.

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.

Part of the reason it's still fuzzy is that xdisp.c seems to recompute
the matrices when it finds a "garbaged" frame, 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).


        Stefan