Re: Conceptually understanding Core Animation
Re: Conceptually understanding Core Animation
- Subject: Re: Conceptually understanding Core Animation
- From: Scott Anguish <email@hidden>
- Date: Fri, 18 Jan 2008 07:37:59 -0500
On Jan 18, 2008, at 6:01 AM, Joachim wrote:
I'm sorry for asking these basic questions, but I have a hard time
understanding some of the CoreAnimation concepts fully. This is a
follow-up on (http://www.cocoabuilder.com/archive/message/cocoa/2008/1/14/196457
).
Even after having read the CA Guide, I don't understand what "state"
a layer is left in after having animated it:
Keep in mind that the Core Animation architecture has 3 components:
layer tree, presentation tree and the render tree (discussed in Core
Animation Architecture).
The layer tree holds the model values (that is the real values of the
various animatable properties)
The presentation tree holds the currently displayed values (the values
as an animation is in flight)
The render tree is responsible for actually compositing it all.
If you use an implied animation (change the value in the layer) the
animation occurs over time. I think this is probably clear to everyone.
If you use an explicit animation (from the first chapter)
<excerpt>
Animatable properties can also be explicitly animated. To explicitly
animate a property you create an instance of one of Core Animation’s
animation classes and specify the required visual effects. An explicit
animation doesn’t change the value of the property in the layer, it
simply animates it in the display.
</excerpt>
<comment>
I see where this should be repeated in the Animation chapter and the
Architecture chapter. I've made a note of this.
</comment>
so they only have an effect on the presentation layer.
So, you do your explicit animation...
When I'm animating a sublayer, explicitly in my case, I'd expect the
layer's property after the animation to be that of the toValue. But
it isn't - even if I set the fillMode like below:
// Code from myLayer.m
CABasicAnimation *anim = [CABasicAnimation
animationWithKeyPath:@"position"];
anim.toValue = [NSValue valueWithPoint:endPos];
anim.timingFunction = [CAMediaTimingFunction
functionWithName:kCAMediaTimingFunctionEaseInEaseOut];
anim.duration = MyAnimationDurationFromPointToPoint
(startPos, endPos);
anim.fillMode = kCAFillModeForwards;
anim.removedOnCompletion = NO;
anim.delegate = self;
[self addAnimation:anim forKey:@"position"];
The reason you're not seeing the position value be the end value is
that it isn't supposed to be. You're only changing the presentation
layer using explicit animations. when you ask for the position value
you're asking for the layer-tree value.
Even though the layer appears at endPos after the animation, the
layer's position property is still startPos. That doesn't make sense
to me. At all.
layer tree, presentation tree
And if I then call [self.superlayer setNeedsDisplay] in the -
animationDidStop:finished: delegate method, the just animated layer
simply disappears). If I set the layer's position to endPos after
animation, the layer jumps to startPos and animates from startPos to
endPos using the default animation values (implicit animation, I
guess).
Yes. if you turn off animation temporarily using a transaction in the
animationDidStop:finished: implementation, then change position, you'd
be find. Turning off animations is discussed in the Transactions
chapter.
- How do I get the layer to stay at the endPos after an explicit
animation?
That's above.
- Am I "wrong" in using layers instead of views as my main visual
element class?
not necessarily.
The user must be able to click on them and drag them around. Think
of a card game type of application.
Have a look at GeekGameBoard to see how they do this exact thing.
If I don't set removedOnCompletion to NO, the layer goes back to
startPos after animation although, conceptually, we're just talking
about removing the animation - after it's done. This is where I
don't understand the concept, because I'd think that the animation
is just the WAY the layer goes from start to end. Once the layer has
been animated, and it's at its end position, the animation's role is
over. I think the documentation could do a better job of explaining
these issues.
It appears it could. (I've made notes)
remember that animations are essentially 'actions' (Actions chapter).
removedOnCompletion basically means "is the animation removed from the
layer's animations when it is done". this is a convenience basically,
it means that if you intend to use the animation once, you don't need
to implement the delegate method to remove from the animation from the
layer explicitly upon completion.
The fillMode controls what happens visually when the animation is
completed. If it is set to none, then it is removed and the layer
value is used instead. if it is set to one of the other modes it will
still be displayed (in the state specified by that fillMode), but only
as long as the animation is still 'attached' to the layer.
Another thing that puzzles me with regards to the animation object
is that it doesn't go away from the layer even if I call [self
removeAllAnimations] in my animationDidStop:finished: delegate
method. Calling [self animationForKey:@"position"] after -
removeAllAnimations (or -animationForKey:@"position"), it still
returns the animation object.
all removeAllAnimations does is clear out the animations that are
attached to the layer in the actions dictionary. it doesn't change the
fact that the layer actually has default animations for "position"
that are acquired elsewhere. the animations you attach to a layer
(stored in the actions dictionary) are simply the first place
animations are looked for. after that the delegate gets a shot if it
implements the correct method, and then the layer itself gets a shot.
it is the layer class that provides the default animation that you're
getting back.
<comment>
This could definitely be clearer. I've made a note.
</comment>
I'm thinking of layers as lightweight views, in broad terms, but I
must be making some wrong assumptions in doing so.
Nope.. that's right.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden