On 5 Aug 2012, at 03:00, Dave Keck wrote: >> I'm unsure of the wisdom of this approach. Presumably the scroll view is >> intentionally blocking the runloop, and thus assuming that the runloop will >> not fire its event sources until after the scrolling is complete. By waking >> up the runloop, you're violating that assumption and could be causing work >> the scrollview has enqueued to be performed sooner than expected. > > During a single scrolling maneuver in 10.8.0, the run loop toggles > many times between NSDefaultRunLoopMode and NSScrollEventCoallescing. > I suppose I could check whether the main run loop is in the default > mode before waking it up, but the overheard of that likely defeats the > purpose, especially considering the inherent race condition. In the > end, waking the main thread up at the wrong time (while it's in > NSScrollEventCoallescing) probably wastes a mach_msg_send, a > mach_msg_receive, and 20 instructions as the scrolling machinery sees > that there's no new event and goes back to sleep or times-out and > returns to the NSApplication loop.
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. _______________________________________________ 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
