Re: Core Animation animations stop prematurely at random

2011-05-17 Thread Bill Cheeseman

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

2011-05-17 Thread Kyle Sluder
On Tue, May 17, 2011 at 11:35 AM, Bill Cheeseman  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

2011-05-17 Thread Bill Cheeseman

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

2011-05-17 Thread Kyle Sluder
On Tue, May 17, 2011 at 10:21 AM, Keith 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
>
> 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

2011-05-17 Thread Keith Duncan

> 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

2011-05-17 Thread David Duncan
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

2011-05-17 Thread Bill Cheeseman

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

2011-05-17 Thread David Duncan
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

2011-05-17 Thread Bill Cheeseman

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

2011-05-16 Thread Matt Neuburg
On Mon, 16 May 2011 08:11:36 -0400, Bill Cheeseman  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, 
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