On Fri, May 21, 2010 at 10:37 AM, Troy Stephens <tsteph...@apple.com> wrote: > 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.)
Hmm. Perhaps instead of using geometryFlipped on our layer, we should manually calculate the bounds rectangle as appropriate? Or would setting the anchor point to (0,1) suffice? Basically, we want to lay out our contents like a text view would, which means that we want our first row of stuff (which is contained in a child layer) to appear at the upper left of the view, which should be at (0,0) in the layer's bounds coordinate space. > 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.) Indeed it does. :) I had tested that, and was actually contemplating adding a button to toggle that behavior, but I wound up heading down the road of "rewrite NSScrollView using CAScrollLayer" instead. > 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. > 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. I can't believe we've overlooked this method. We do, however, need to resize the layer vertically as our document grows/shrinks, and we need it to always be at least as high as the visible area of the scroll view. Does this have the same potential for conflict with AppKit's layer resizing? (Or perhaps if we just resize the view to the appropriate size, this entire question just goes away. But that can't be right, it doesn't involve impossible contortions and overriding private methods! <grin>) > 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. The CAGradientLayer is a red herring that I was using to visually establish which end of the layer was "up." You and David have been thoroughly amazing with your help. Thanks so much! --Kyle Sluder _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
