On Mon, Aug 6, 2012, at 05:34 PM, Dave Keck wrote:
> > But Mike is still right; you're probably better served by using
> > -performSelectorOnMainThread::: rather than waking the run loop up yourself.
>
> I tend to disagree -- invoking CFRunLoopPerformBlock() and
> CFRunLoopWakeUp() is likely more
> But Mike is still right; you're probably better served by using
> -performSelectorOnMainThread::: rather than waking the run loop up yourself.
I tend to disagree -- invoking CFRunLoopPerformBlock() and
CFRunLoopWakeUp() is likely more performant since they're at the CF
level (which -performSele
On Aug 6, 2012, at 2:44 AM, Dave Keck 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.
> 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 mod
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,
> 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 c
On Aug 4, 2012, at 4:43 PM, Dave Keck wrote:
> I'm afraid I sent my question before doing my due diligence though, so
> in the interest of the archives: the reason the invalidated regions
> weren't being redrawn during scrolling was because the block that
> calls -setNeedsDisplayInRect: was sched
Hi Quincey,
> For the latter, it seems hardly surprising that the content wouldn't appear
> until you stop scrolling, since by setting the copy-on-scroll flag you've
> promised that the old view contents don't change during scrolling.
The docs don't say one way or another, but on both 10.7 and 10
On Aug 4, 2012, at 14:35 , Dave Keck wrote:
> I'm working on a scrollable grid view and noticed that its appearance
> during scrolling has regressed since installing 10.8.
>
> This grid view loads content in the background and calls
> -setNeedsDisplayInRect: (thread-safely) as content becomes av
I'm working on a scrollable grid view and noticed that its appearance
during scrolling has regressed since installing 10.8.
This grid view loads content in the background and calls
-setNeedsDisplayInRect: (thread-safely) as content becomes available.
With copy-on-scroll enabled, -setNeedsDisplayI
10 matches
Mail list logo
