Re: Deferring a selector until later, but before painting
Re: Deferring a selector until later, but before painting
- Subject: Re: Deferring a selector until later, but before painting
- From: Chris Suter <email@hidden>
- Date: Thu, 6 Mar 2008 12:43:06 +1100
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
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden