Re: Redisplay problems?

[Eli Zaretskii]

> Date: Thu, 20 Mar 2014 20:22:38 +0100
> From: martin rudalics <address@hidden>
> Cc: Christian Lynbech <address@hidden>, James Cloos <address@hidden>,
>       "Kan-Ru Chen (陳侃如)" <address@hidden>,
>       address@hidden
> 
>  > 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.

As I wrote elsewhere, I see no reason for marking such a frame
"garbaged", because its glyph matrices are just fine.  Unless you can
show me some code that avoids recomputing or invalidating the matrices
of an iconified frame.

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

Yes, all of them.  The glyph matrices of all the windows of such a
frame are invalidated by clear_garbaged_frames, which is called at the
beginning of a redisplay cycle.

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

I think Stefan wanted to say that "garbaged" means redraw more than
just the parts that have changed.

If you read my description, I explained that a "garbaged" frame means
Emacs does not believe the contents of the current glyph matrices for
that frame is reliable.  So it discards them, and that forces a
complete redraw of all the windows on the frame.

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

If the glyph matrices of such a frame were updated when the contents
changed, then there's no need to recompute them at expose event time.

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

Actually, the desired glyph matrices are always recomputed when we
enter redisplay.  But if the result is identical to the current
matrix, then nothing is redrawn.

When a frame is marked "garbaged", Emacs clears the current glyph
matrices, so it loses the ability to optimize the redraw phase of the
redisplay cycle, because there's nothing with which to compare the
desired matrices.