Re: Deferring a selector until later, but before painting

FROM : Chris Suter
DATE : Thu Mar 06 02:43:06 2008

On 06/03/2008, at 12:12 PM, John Stiles wrote:

> There are many times in my code where I want to defer a selector's 
> execution until the next time the event loop runs, which is a 
> perfect match for -performSelector:withObject:afterDelay:, passing a 
> delay of 0.0. However, this executes after the app has repainted all 
> the windows. Is there a way to get a selector called later, but 
> before windows paint?
>
> Right now in my app, there are some controls which appear and then 
> their state changes a fraction of a second later, and I'd like to 
> avoid the visually jarring "pop" effect of a control which changes 
> itself right after first appearing, but I can't find an easy way to 
> avoid deferring some operations.


If the above is the case, I don't see how defering the selector's 
execution is going to help.

What I guess is happening at the moment is:

1. Control is added.

2. View is re-displayed.

3. State changes.

4. View is re-displayed

Deferring the selector in the way you want is still going to put the 
addition of the control before 2.

Why are you worried about the application drawing twice—I mean what's 
wrong with just delaying the display of the control until after the 
first window paint? Is there a performance issue?

- Chris