Hi Gideon, While at first glance this looks horrendous, it does seem to be stuck in a low-level image rasterizing operation, and the call stack suggests it's in a sublayer. So it is pointing to your layer-hosting subview as the culprit. When scrolling or zooming "normally" it might be able to avoid this because only newly revealed or uncached areas need to be redrawn and that may well not include the subview, but for -scrollToPoint: it's possible that it can't do this for some reason (though it's not clear exactly why, but often the whys and wherefores of Apple's code are a bit mysterious), so has to re-render everything.
Can you temporariy remove your layer-backed subview to see if it speeds up? If so, then there's at least the place to focus your efforts. It seems to be rasterizing an image, so there could be a bottleneck there, for example scaling a huge image to a small region, or vice versa. --Graham > On 18 Nov 2014, at 12:58 am, Gideon King <[email protected]> wrote: > > I have always done this using scrollPoint on my view. I have been using this > since 10.6. My view is not layer backed and has a single subview which is a > layer *hosting* view. > > Now in Yosemite 10.10, this takes a *very* long time at 100% CPU, with a > stack trace looking something like this: > > CoreGraphics`argb32_sample_argb32 + 621 > CoreGraphics`argb32_image_mark + 1696 > CoreGraphics`RGBA32_image + 1156 _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
