Re: [Bibdesk-develop] Lazy BDSKMainTableView rebuildTrackingRects

[Christiaan H. <cmh...@gm...>]

On 10 Jun 2008, at 2:36 AM, Adam R. Maxwell wrote:

> In article <653...@co...>,
> "Colin A. Smith" <co...@co...> wrote:
>
>> I've found that when using the trackpad to scroll in a
>> BDSKMainTableView, the responsiveness can be poor and jumpy. I traced
>> the problem to rebuildTrackingRects getting fired after scrolling to
>> each new position, and then taking a relatively long time to execute.
>
> What did the profiles look like?  Was it memory or processor  
> intensive?
> I'm curious because I've observed tracking rects as a minor  
> performance
> hit on FileView as well, mainly due to Leopard creating a large number
> of temporary objects.
>
>> The solution I came up with was to delay calling rebuildTrackingRects
>> until after the user moves the mouse for the first time after an
>> rebuild is needed.
>>
>> Because NSWindow objects by default do not respond to NSMouseMoved
>> events by default, the easy way to do this is to toggle enable
>> acceptsMouseMovedEvents until the user moves their mouse, then have
>> the corresponding mouseMoved message disable acceptsMouseMovedEvents
>> and call rebuildTrackingRects.
>
> Clever :).  Does it help at all to do something like [[OFMessageQueue
> mainQueue] queueSelectorOnce:... for rebuildTrackingRects?  That might
> be more future-proof.
>
> -- 
> Adam
>

Unfortunately this won't do it. When you'd use this, tracking rects  
are only updated after a mouse moved while the table is active. There  
are many more situations where the tracking rects need to be updated.  
I've had lots of difficulties with non-updated tracking rects in Skim,  
even when I was convinced I had covered all possible updates I didn't.

Christiaan