Re: Redisplay problems?

[Eli Zaretskii]

> From: Stefan <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden,  address@hidden,  
> address@hidden
> Date: Fri, 21 Mar 2014 08:59:37 -0400
> 
> > When the display is messed up (for some value of "messed up"), we
> > cannot trust the current glyph matrices anymore.
> 
> It all depends on the reason for the "messed up".  E.g. it can be messed
> up because some code drew something on screen without going through
> "change matrices and reflect that change on screen".

Emacs doesn't (and cannot) do that, AFAIK.  But maybe I misunderstand
what you mean.

> That's what I would understand as the "natural meaning" for
> "garbaged" (and in that case the matrices might still be trusted to
> reflect "what we'd like to see on screen").

I didn't say it was natural, I tried to explain what it does.

> So, IIUC this "natural meaning" is wrong.  And "garbaged" is really
> meant to say "disable all optimizations".

If you include "smart" redrawing in optimizations, then yes, you could
say that.

> Which then begs the question: what is the difference with
> `prevent_redisplay_optimizations_p'?

That one only prevents optimizations in computing the desired
matrices, AFAIR.  It has no effect on actual redrawing in
update_frame.

> > 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.
> 
> Indeed and I think that's right because the expose_frame calls will be
> performed later in response to expose events.

Where do you see expose_frame called in response to expose events?
That's what I didn't see.