Re: Redisplay problems?

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Mon, 24 Mar 2014 09:32:20 +0100
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: Stefan <address@hidden>
> >> Cc: address@hidden, address@hidden, address@hidden, address@hidden,
> >>         address@hidden
> >> Date: Sun, 23 Mar 2014 21:58:32 -0400
> >> 
> >> > I actually don't think we should be bothered about this at all.  Why
> >> > does it make sense to optimize the use case where a frame is
> >> > deiconified?
> >> 
> >> If you have 50 frames, 25 on one desktop and 25 on the other, whenever
> >> you switch from one desktop to the other, 25 frames get deiconified and
> >> the other 25 get iconified.
> >
> > I still don't see anything performance critical even in this scenario.
> > A switch to a different desktop is not something one would do several
> > times a second, and it's okay for it to take a second or so.
> 
> It is quite customary to _cycle_ through desktops and go through several
> in fast succession until finding the desired one.  Most certainly at a
> rate of several (three or four) per second.

You took what I wrote too literally, I think.  What you describe
deiconifies frames at higher rate, but only momentarily so.  Once the
desired desktop is located, the user will stay with it for some time,
until she again switches.  So I still see no reason to regard this as
performance critical.

OTOH, when we need to deiconify a frame, or expose a large portion of
it, I see no space for significant optimizations anyway.  Redisplay
optimizations are about redrawing as small portions of the frame as
possible.  But in the case in point, we basically need to redraw the
entire frame -- how much can you win here anyway?