> On 24 Mar 2016, at 1:38 PM, Graham Cox <graham....@bigpond.com> wrote: > > I could also subclass NSScrollView - this is probably my next approach - but > I’m hoping there’s an easier way. I need to see what is invoking the scroll > of the document (image browser) view. >
OK, I’ve now done this and intercepted -reflectScrolledClipView: The results are interesting - here’s the stack trace of what’s causing each scroll: #0 0x000000010004ddfe in -[GCDebuggingScrollView reflectScrolledClipView:] at GCDebuggingScrollView.m:19 #1 0x00007fff897f53f9 in -[IKImageBrowserView(ImageBrowserScrolling) adjustScroller] () #2 0x00007fff897f57df in -[IKImageBrowserView(ImageBrowserScrolling) adjustDocumentSize] () #3 0x00007fff897ef55b in -[IKImageBrowserView(ImageBrowserLayout) updateLayoutOfCellsAtIndexes:] () #4 0x00007fff897b67d7 in -[IKImageBrowserView(ImageBrowserImport) _didImportCellsAtIndexes:] () #5 0x00007fff897b6d83 in -[IKImageBrowserView(ImageBrowserImport) didImportCell:thumbnail:] () #6 0x00007fff9650fa6c in __invoking___ () #7 0x00007fff9650f8fe in -[NSInvocation invoke] () #8 0x00007fff99318f5e in __NSThreadPerformPerform () #9 0x00007fff96533881 in __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ () #10 0x00007fff96512fbc in __CFRunLoopDoSources0 () #11 0x00007fff965124df in __CFRunLoopRun () #12 0x00007fff96511ed8 in CFRunLoopRunSpecific () #13 0x00007fff99637935 in RunCurrentEventLoopInMode () #14 0x00007fff9963776f in ReceiveNextEventCommon () #15 0x00007fff996375af in _BlockUntilNextEventMatchingListInModeWithFilter () #16 0x00007fff90b77efa in _DPSNextEvent () #17 0x00007fff90b7732a in -[NSApplication _nextEventMatchingEventMask:untilDate:inMode:dequeue:] () #18 0x00007fff90b6be84 in -[NSApplication run] () #19 0x00007fff90b3546c in NSApplicationMain () So for every imported cell, the browser view gets -didImportCell:thumbnail: and this eventually calls -adjustDocumentSize: (which does NOT call -setFrameSize: most of the time) but does call -adjustScroller which pushes the scroll position down (it doesn’t scroll all the way to the bottom each time, but scrolls some distance towards the bottom - eventually it will reach the bottom and stop. ). This gets called a lot - far more times than there are cells in the view. For example, for 16 image cells, this gets called over 150 times. Each cell is imported on a background thread, but this is invoked on the main thread. This fits my theory that it’s the background activity that’s triggering this, as it stops when all images are loaded. What’s not clear is why there are so many invocations - far more than one per cell (might be one of Apple’s misguided attempts at auto-animating something by inetrpolation). However setting the -animates property on the IKImageBrowserView doesn’t make a difference. The big question is why -adjustScroller thinks it should be scrolling the view, and why in previous builds it did not. Clearly, this has changed in 10.11.4 (or at some point, and conditionally calls new code based on which SDK I compiled with) since this was always well behaved until now. —Graham _______________________________________________ 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
