On Aug 6, 2012, at 2:44 AM, Dave Keck <davek...@gmail.com> wrote:

>> Right, so what you actually want to do is change how you’re messaging the 
>> main thread. Use something like 
>> -performSelectorOnMainThread:withObject:waitUntilDone:modes: so you can 
>> specify NSDefaultRunLoopMode and NSScrollEventCoallescing.
> 
> NSScrollEventCoallescing is a private run loop mode so I'd avoid using
> it since the Cocoa machinery is completely within its rights to assume
> that no outside sources/timers/observers fire in that mode. (Just
> wanted to mention it since I've been bitten by related issues before.)

But Mike is still right; you're probably better served by using 
-performSelectorOnMainThread::: rather than waking the run loop up yourself.

Given that it's a private mode, I'm not sure you really want your code 
executing during the scroll event coalescing mode. Of course since it's private 
we don't know exactly what's going on during this mode. My best guess is that 
-[NSEvent trackSwipeEventWithOptions:…] runs this mode periodically for short, 
defined periods of time to catch cases where the user flicks the trackpad and 
then puts their finger back down to stop momentum scrolling or change its 
direction.

Regardless of what it's doing, the more I think about it the more I think Apple 
should document this mode. Since scroll event coalescing is related to the main 
dispatch queue not being drained, scrolling's use of the run loop seems like 
something that really needs to be documented in full.

Perhaps file an enhancement request and a doc bug?

--Kyle Sluder
_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to