On Fri, May 21, 2010 at 11:06 AM, Troy Stephens <tsteph...@apple.com> 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 (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