You probably spoke with me, so I'll go ahead and fill in the details :).
On Feb 16, 2009, at 11:50 AM, E. Wing wrote:
If memory serves, the problem was that AppKit was too aggressive about
freeing the layer-backing of the NSViews it owns. My application was a
mixure of both NSViews and CALayers. I think I was told that Apple
didn't
like me mixing the two to the aggressive degree I was doing.
AppKit will basically release layers that it owns when the associated
view is not onscreen. Things like hiding a toolbar, switching the view
in a tab view, or removing a view from a window will all cause the
layer to be released. This is neither an exhaustive list, nor
something that you should rely upon in your application.
I was told that for every NSView I used, I should subclass setLayer
which
gives you a chance to intervene in the setup/tear down process. But
I forgot
most of the details.
The simplest solution, if you can mange it, is to set the view's layer
to your own layer, at which point AppKit will take a hands off
approach and allow you to determine when the layer should go away.
The alternative, which is primarily for use if you need AppKit to
continue to draw to the view's layer, is to override -setLayer: to do
any required setup for your layer tree. So what you would do is check
if the incoming layer is non-nil, and if it is, make any changes to
that layer (including adding sublayers) at that point.
--
David Duncan
Apple DTS Animation and Printing
_______________________________________________
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
