Re: Layer-hosting views and layer-backed scroll views
Re: Layer-hosting views and layer-backed scroll views
- Subject: Re: Layer-hosting views and layer-backed scroll views
- From: Troy Stephens <email@hidden>
- Date: Fri, 21 May 2010 10:37:50 -0700
Hi Kyle,
On May 20, 2010, at 12:12 PM, Kyle Sluder wrote:
> On Thu, May 20, 2010 at 9:52 AM, Kyle Sluder <email@hidden> wrote:
>> I have uploaded a sample project to
>> http://www.lanechng.com/ScrolledLayerHostingView.zip. Resize the
>> window to see the problem in action; then click one of the scroll
>> arrows to see it fix itself.
>
> Well, I've filed rdar://problem/8009542 with this demo project
> attached. I've also been informed that IKImageBrowserView isn't
> flipped, perhaps because of this very same issue. It's also the only
> class besides NSView to implement _updateLayerGeometryFromView.
> Needless to say, I'm more than a little suspicious that scroll views
> are just plain broken.
>
> --Kyle Sluder
CALayers don't support the same notion of "flippedness" that NSView's geometry model uses. (CALayer's "geometryFlipped" property is recursive in its effect, so isn't semantically identical.)
Therefore, whenever AppKit resizes the backing layer of a flipped NSView, we have to compute and assign new "position" values for its sublayers, to keep them in the same place relative to the top left. (Don't count on this not changing in a future release, but for debugging purposes you can look for -_updateSublayerPositionsForFlippedSuperview, which gets invoked from -setFrameSize:)
We do this for sublayers that we created and therefore consider ourselves to "own", but in your test app you're instantiating and assigning a layer of your own to the documentView. Therefore, when we resize the ClipView's backing layer (and the ClipView is flipped, because it always matches the flippedness of the ScrollView's documentView), we don't touch the position of your documentView's layer. (If you modify your example to omit the custom layer creation and -setLayer:, and instead override -drawRect: to draw your content into the view's AppKit-provided backing layer, you'll see the problem goes away.)
Arguably it would actually be OK for us to modify the layer's position in this case (and clearly our "hands off" policy isn't quite consistent about this, since, as you noted, scrolling will "fix" the incorrect document layer position).
Meanwhile, the simplest solution, if you require a custom backing layer, is to override NSView's -makeBackingLayer method (added in 10.6) to instantiate and return your (autoreleased) layer. When layer instantiation goes through this path, AppKit considers the layer AppKit-owned, so you won't run into the positioning problem.
By the way: I don't know whether CAGradientLayer disregards -setNeedsDisplay (since the layer renders its content programmatically), possibly making this irrelevant in practice, but in cases like this, where you provide a layer of your own that already has content, and you don't want AppKit to ever invoke the view's -drawRect: to draw view content into the layer, it's a good idea to -setLayerContentsRedrawPolicy:NSViewLayerContentsRedrawNever on the view.
Troy Stephens
AppKit
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden