In article <[EMAIL PROTECTED]>, Christiaan Hofman <[EMAIL PROTECTED]> wrote:
> On 7 Mar 2008, at 5:26 AM, Adam Maxwell wrote: > > > In article <[EMAIL PROTECTED]>, > > Christiaan Hofman <[EMAIL PROTECTED]> wrote: > > > >> I also changed the batching of > >> results a bit, which avoids some lock/unlock steps there (basically > >> use makeObjectsPerformSelector on a temporary array instead of > >> separately sending the operations a start message). Did not make much > >> difference though. Probably it is also not the bottleneck, as the > >> iconUpdated: messages don't seem to come very fast. > > > > Right, batching there should be unnecessary now; it was a hack > > previously to keep from flooding the main CFRunLoop with a bunch of > > updates. > > You mean keeping the _activeOperations around? Indeed, - > [FVIconUpdateOperation start] returns immediately, so it seems all it > does is add some locks. However, that's an implementation detail, the > queue doesn't know about that. For all it cares, it could spawn > another thread. I was speaking of the FVIconQueue batching as a hack. Keeping _activeOperations around is for cancelling them, at this point, though it was originally used for batching callbacks to the main thread. There are certainly alternate approaches there; I went with draining the queue one-by-one so the check for the number of operations was easy. > > The iconUpdated: call is also significantly more efficient due > > to the index mapping, which avoids hashing URLs and collecting them > > (slow). > > > > Maybe that was the reason why iconQueue stopped working for me? After > copying some partial changes from your version (I think it was changes > to the icon classes and also the index mapping), the iconQueue kept > firing with the old icons after the URLs had changed, so the view was > never updated. Never really understood why. This was the reason I > copied also the operation queue stuff. That sounds like a bug somewhere. I'd expect the old queue to keep working, but obviously never tried it. -- adam ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bibdesk-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/bibdesk-develop
