Re: Core Animation animations stop prematurely at random
On May 16, 2011, at 8:11 AM, Bill Cheeseman wrote: When I quit and relaunch the application, the animations sometimes don't run for the full specified duration when I hit the hot key. During any given run of the application, the animations either work correctly every time I hit the hot key, or they stop prematurely every time I hit the hot key. Answering my own question: Although it's hard to be sure that a random problem is really fixed, it appears that the solution was to stop creating Core Animation layers in the view's -initWithFrame: method and instead create them in the view's -awakeFromNib method. I was aware that the layer tree should not be built (with -addSublayer) in -initWithFrame:, but none of the commentaries I read suggested to me that you can't even create the layers in -initWithFrame: and store them in iVars for later use. -- Bill Cheeseman - b...@cheeseman.name ___ 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
Re: Core Animation animations stop prematurely at random
On May 17, 2011, at 1:26 AM, Bill Cheeseman wrote: Answering my own question: Although it's hard to be sure that a random problem is really fixed, it appears that the solution was to stop creating Core Animation layers in the view's -initWithFrame: method and instead create them in the view's -awakeFromNib method. I was aware that the layer tree should not be built (with -addSublayer) in -initWithFrame:, but none of the commentaries I read suggested to me that you can't even create the layers in -initWithFrame: and store them in iVars for later use. There should be no actual restriction like that however. That said, as you point out, if you have view that supports layers and come from a nib, you often have to duplicate work to allow it to work in both situations. -- David Duncan ___ 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
Re: Core Animation animations stop prematurely at random
On May 17, 2011, at 11:33 AM, David Duncan wrote: There should be no actual restriction like that however. That said, as you point out, if you have view that supports layers and come from a nib, you often have to duplicate work to allow it to work in both situations. I'm not sure I follow you. I am aware that there are a number of commentaries explaining that loading a nib file that contains accessibility settings interferes with a layer tree that was constructed in code before the nib was loaded -- hence the recommendation to construct the layer tree in -awakeFromNib, not in -initWithFrame:. However, my view's nib file does not use any of the Interface Builder accessibility features, so I'm not at all clear why I should have run afoul of this issue. Apple's documentation on the point is quite cryptic. -- Bill Cheeseman - b...@cheeseman.name ___ 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
Re: Core Animation animations stop prematurely at random
On May 17, 2011, at 9:49 AM, Bill Cheeseman wrote: On May 17, 2011, at 11:33 AM, David Duncan wrote: There should be no actual restriction like that however. That said, as you point out, if you have view that supports layers and come from a nib, you often have to duplicate work to allow it to work in both situations. I'm not sure I follow you. I am aware that there are a number of commentaries explaining that loading a nib file that contains accessibility settings interferes with a layer tree that was constructed in code before the nib was loaded -- hence the recommendation to construct the layer tree in -awakeFromNib, not in -initWithFrame:. However, my view's nib file does not use any of the Interface Builder accessibility features, so I'm not at all clear why I should have run afoul of this issue. Apple's documentation on the point is quite cryptic. The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again. As such, if you did anything that relied on the view being layer backed (such as setting its layer and manipulating the layer tree) then that work needs to be done again. However, this should not apply to any layers you create that aren't implanted into the view. You should be able to create layers to your hearts content inside of -initWithFrame: as long as you don't try to manipulate the view's layer tree. As such your statement that you couldn't create layers there seems to be indicative of some other issue. My addendum is if you are creating a view that should both support loading from a nib, and creation purely in code. In that situation, you basically need to duplicate the layer setup code, since -awakeFromNib won't be called in the programmatic case, while in the nib case you may need to re-do some work that is done in -initWithFrame:. If only nib loading called -initWithCoder: on Mac OS X :). -- David Duncan ___ 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
Re: Core Animation animations stop prematurely at random
The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again Would there be any issue with overriding -setWantsLayer: to drop the [view setWantsLayer:NO] invocation, only allowing [view setWantsLayer:YES] to pass through to the NSView implementation? thanks, Keith ___ 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
Re: Core Animation animations stop prematurely at random
On Tue, May 17, 2011 at 10:21 AM, Keith Duncan ke...@33software.com wrote: The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again Would there be any issue with overriding -setWantsLayer: to drop the [view setWantsLayer:NO] invocation, only allowing [view setWantsLayer:YES] to pass through to the NSView implementation? Well, there's no guarantee that nib loading goes through -setWantsLayer:. --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
Re: Core Animation animations stop prematurely at random
On May 17, 2011, at 12:58 PM, David Duncan wrote: The basic problem comes about when a view in the nib has wantsLayer=NO, but the view itself always wants to be layer backed. If you setWantsLayer:YES inside of -initWithFrame:, then by the time you get to -awakeFromNib wantsLayer=NO again. As such, if you did anything that relied on the view being layer backed (such as setting its layer and manipulating the layer tree) then that work needs to be done again. I get it. Thanks. However, this should not apply to any layers you create that aren't implanted into the view. You should be able to create layers to your hearts content inside of -initWithFrame: as long as you don't try to manipulate the view's layer tree. As such your statement that you couldn't create layers there seems to be indicative of some other issue. I agree that the explanation doesn't logically lead to a prohibition on creating layers in -initWithFrame:. That's why I initially created them there, deferring only the construction of the layer tree to -awakeFromNib. But I suffered random failures -- in fact, the application failed more often than not. The randomness is consistent with my doing something to which the phrase undefined behavior is often applied in Apple documentation. Now that I've moved the layer creation to -awakeFromNib, however, my application is working correctly 100% of the time. 100% of past time, that is. As to future time, I don't know yet. ;- That's the trouble with random failures -- Bill Cheeseman - b...@cheeseman.name ___ 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
Re: Core Animation animations stop prematurely at random
On Tue, May 17, 2011 at 11:35 AM, Bill Cheeseman wjcheese...@gmail.com wrote: I agree that the explanation doesn't logically lead to a prohibition on creating layers in -initWithFrame:. That's why I initially created them there, deferring only the construction of the layer tree to -awakeFromNib. But I suffered random failures -- in fact, the application failed more often than not. The randomness is consistent with my doing something to which the phrase undefined behavior is often applied in Apple documentation. Now that I've moved the layer creation to -awakeFromNib, however, my application is working correctly 100% of the time. You could also try using -makeBackingLayer. That's useful if your view can be used both programmatically and in a nib. --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
Re: Core Animation animations stop prematurely at random
On May 17, 2011, at 2:58 PM, Kyle Sluder wrote: You could also try using -makeBackingLayer. That's useful if your view can be used both programmatically and in a nib. I wonder if that method works for a layer-hosting view, which is what my view is -- not a layer-backed view. But even if it can be used in creating a layer-hosting view, I don't understand what it might accomplish. -- Bill Cheeseman - b...@cheeseman.name ___ 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
Re: Core Animation animations stop prematurely at random
On Mon, 16 May 2011 08:11:36 -0400, Bill Cheeseman wjcheese...@gmail.com said: My Mac OS X application has an borderless transparent overlay window with a layer-hosting view. The view's layers add a bunch of animations in response to a hot key. It all works correctly -- sometimes. What could account for sublayer animations prematurely stopping on random application launches? I've tested everything I can think of. Can you boil the problem down to minimal code and show it? I'm wondering whether you're accidentally removing the animation by adding another animation with the same key, for example; but that's a totally wild guess based on nothing (because there's nothing in your question to base it on)... m. -- matt neuburg, phd = m...@tidbits.com, http://www.apeth.net/matt/ A fool + a tool + an autorelease pool = cool! Programming iOS 4! http://www.apeth.net/matt/default.html#iosbook___ 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
