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: Kyle Sluder <email@hidden>
- Date: Fri, 21 May 2010 11:23:09 -0700
On Fri, May 21, 2010 at 11:06 AM, Troy Stephens <email@hidden> wrote:
> You can use geometryFlipped on your documentView's layer for this purpose, if and only if your documentView isn't going to have any subviews. If you control all the content (build it out of your own layers) from there on down, you're OK. If AppKit has to position subview backing layers within the documentView's layer, it won't take the geometryFlipped setting into account and the positioning won't turn out right.
We're already following David's advice and putting our field editors
in a companion layer-backed view that is a peer of our document view
(but whose layer we don't disturb). But it was briefly funny when
field editors would appear upside down and at the opposite end of the
document from the content they were editing. :)
> You should never modify the anchorPoint of a view backing layer. If you modify your code to override -makeBackingLayer, AppKit will set the returned layer's anchorPoint automatically the way it wants it (to (0,1) if the superview is flipped, or (0,0) if the superview is unflipped).
Hmm. Are we free to move the bounds origin, though? We always want to
put the layer's bounds origin at the upper left, and for one instance
of this view we want to inset the origin by about 20px. This has
wreaked havoc with AppKit's custom layer content provider (which
apparently maps layer positions directly to CGImageSource points for
the purposes of calling -drawRect:, and has trouble when either
coordinate is negative). The result was a black 20px-wide stripe down
the left side of the view.
We did solve this at one point (when we were still abusing
layer-backed drawing) by turning off drawsBackground on the scroll
view, and inserting a custom sublayer with a background color. Then
AppKit's image source isn't invoked at all (or if it is, it doesn't
draw anything, and then our sublayer draws on top of it). I suppose if
I return my own layer from -makeBackingLayer, then AppKit won't attach
its image source since it won't be trying to hook up the -drawRect:
rendering path?
>>> 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).
>>
>> The inconsistency is what's so maddening. I thought I had just failed
>> to do something on initialization.
>
> We'll look at improving the consistency of this behavior.
Thanks.
> Once you're using -makeBackingLayer, just size the documentView the way you want it, and let AppKit automatically resize the layer to match.
If AppKit does in fact try to attach an image source to the layer
returned by -makeBackingLayer, then we need to match our
background-fill sublayer's size, but that's made a heck of a lot
easier by being able to return a layer with a custom
-resizeSublayersWithOldSize: implementation. Or, at the very worst,
our background-fill layer could listen for bounds KVO from the
view-backing layer.
--Kyle Sluder
_______________________________________________
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