Re: Redisplay problems?

[Eli Zaretskii]

> From: Stefan Monnier <address@hidden>
> Date: Thu, 20 Mar 2014 16:55:52 -0400
> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
>       address@hidden
> 
> >> So "garbaged" means that we should not try to only redraw the parts that
> >> have changed.
> > When redisplay finds that a frame is "garbaged", it marks all of its
> > glyph matrix rows "disabled".  This will force their complete
> > redrawing, as described above.
> 
> Right, but that's not how "garbaged" is described (e.g. in the comment
> before it: "True if this frame should be redrawn"), hence the fuzzyness.

I never said your fuzzyness is not justified.  That's why I described
how things really work.

> The way I see it described, "garbaged" means that the display is not in
> sync with the matrices any more, but not that the matrices need to
> be recomputed.
> 
> But the implementation you describe here implies that "garbaged" will
> end up recomputing all the matrices.

When the display is messed up (for some value of "messed up"), we
cannot trust the current glyph matrices anymore.  Another situation is
frame resize: then we _know_ the current matrices are useless.  In
these cases, we must redisplay everything, which must start from
computing the desired glyph matrices.  IOW, Emacs has no way of
performing redisplay, except by computing the desired matrices --
these tell what should be on the screen.

The commentary describes the effect of the "garbaged" flag
(eventually, the frame will indeed be redrawn in its entirety), but it
does not describe the implementation of causing that effect.

> And in turn I suspect some of the code takes advantage of the knowledge
> of how "garbaged" is implemented: it sets "garbaged" to cause the
> matrices to be recomputed (and the frame redrawn redrawn).

As I described, the desired matrices are _always_ recomputed, if we
enter redisplay through redisplay_internal.  (Expose events bypass
that stage.)  So there's no need to cause the matrices to be
recomputed: they always will be.  What you can do is disable the
optimizations that might allow Emacs to recompute only some portions
of the desired matrices.  We currently do that by setting
windows_or_buffers_changed (via fset_redisplay that calls
redisplay_other_windows), when the frame's "garbaged" flag is set.
This disabling of redisplay optimizations is inevitable when the
current matrices cannot be used for comparison with desired ones.  But
if you only want to cause a full re-computation of all the desired
matrices, all you need to do is set windows_or_buffers_changed.  Note,
however, that doing that without also setting the frame's "garbaged"
flag might end up redrawing very little, or nothing at all, if the
recomputed desired matrices are found to be similar or identical to
the current one.  Only setting the "garbaged" flag ensures we will
actually redraw the entire frame, i.e. refresh what's on the glass.

> > I don't think I understand what you meant to say here.  But if you
> > were talking about what to do about a frame that was deiconified, I
> > think you need to call expose_frame, and arrange for the exposed
> > rectangle to cover the entire frame.  That should do what you want, no
> > more, no less.
> 
> Doesn't the windowing-system do that already for us?

If you mean that it somehow magically calls expose_frame, then no, I
don't think so.  We should call it ourselves when the right event(s)
come(s).  I'm not an expert on those parts of Emacs, but it looks to
me that we don't consistently call expose_frame when a frame is
deiconified.  I might be mistaken, though.

Also note that setting the "garbaged" flag makes expose_frame a no-op:
it immediately returns without doing anything, because it knows the
frame will be completely redrawn very soon.