I have a method in which a bunch of layers are positioned, and a single "activated" layer (basically a layer that the user has clicked on) is both positioned and resized at the same time. All the layers, including the activated layer are sublayers of a larger layer. Here is my method:
[CATransaction begin];
[CATransaction setValue:[NSNumber numberWithFloat:0.7]
forKey:kCATransactionAnimationDuration];
}];
for (CALayer *layer in self.inactiveLayers) {
... do some positioning ...
}
CGRect newFrame = activeLayer.frame;
newFrame.origin.x = 50.0;
newFrame.origin.y = 50.0;
newFrame.size.width = 100.0;
newFrame.size.height = 100.0;
activeLayer.frame = newFrame;
[CATransaction commit];
The problem I'm experiencing is really weird. Using the code above, none of the animations run (not even the animations for the inactive layers). But as soon as I comment out the lines that set the size and width of the new frame, the animations magically start working again.
Is there any reason this should be happening?
Figured out the problem, I had a layout manager set on the superlayer of the layers I was trying to animate, and the layout code (which reset the sizes of the layers) was being called when the layer bounds changed. Disabling the layout manager for the duration of the animation solved the issue.
It is because the frame property of a CAlayer is not animatable. Use the bounds property instead and the position animation will run without a hitch.
Related
I'm using a CARenderer to render another CALayer tree into a CAMetalLayer, which I hope to use as the mask of yet another layer. For testing purposes, I've tried adding the CAMetalLayer as a normal sublayer instead of a mask.
The layer object below is not visible after adding it to a superlayer that is definitely visible. I've confirmed the frame of the layer is not a problem. Here's how I'm making the CAMetalLayer and its CARenderer.
CAMetalLayer *layer = [CAMetalLayer layer];
layer.frame = bounds;
layer.device = MTLCreateSystemDefaultDevice();
//layer.opaque = NO;
//layer.framebufferOnly = NO;
id<CAMetalDrawable> drawable = layer.nextDrawable;
_lastDrawable = drawable;
_renderer = [CARenderer rendererWithMTLTexture:drawable.texture options:nil];
_renderer.layer = self.superview.layer;
_renderer.bounds = bounds;
👇 By creating a CIImage and inspecting it with the debugger, I've confirmed the CARenderer is updating the Metal texture.
CIImage *img = [CIImage imageWithMTLTexture:_lastDrawable.texture options:nil];
But when I set the superlayer of the CAMetalLayer, it's nowhere to be seen.
[self.layer addSublayer:layer];
Here's how I'm using the CARenderer:
[_renderer beginFrameAtTime:CACurrentMediaTime() timeStamp:NULL];
[_renderer addUpdateRect:bounds];
[_renderer render];
[_renderer endFrame];
That last snippet runs frequently.
edit 1
I've added a backgroundColor and now the layer is visible, but its texture is not being rendered inside it.
layer.backgroundColor = NSColor.yellowColor.CGColor;
I would recommend just setting the original layer as a mask rather than trying to render it to a texture first; you’re sort of duplicating the work that CA would be doing anyway.
If you really need control over when the mask layer tree gets rendered—and again you should definitely try the standard method first—the right way to do this would be to create an IOSurface-backed MTLTexture rather than using a CAMetalLayer’s drawable, draw into the texture with your CARenderer, set the IOSurface as the contents of a regular CALayer, and use that layer as the mask.
I have encountered something strange with UIView animations. The animation scales a sub view
from a rect to fill its parent view:
//update views
CGRect startRect = ...; //A rect in parentView co-ordinates space that childView appears from
UIView *parentView = ...;
UIView *childView = ...;
[parentView addSubview:childView];
//animation start state
childView.alpha = 0;
childView.center = (CGPointMake( CGRectGetMidX(startRect), CGRectGetMidY(startRect)));
//TODO: set childViews transform and so that it is completely contained with in startRect
childView.transform = CGAffineTransformMakeScale(.25, .25);
[UIView animateWithDuration:.25 animations:^{
childView.transform = CGAffineTransformIdentity;
childView.alpha = 1;
childView.frame = parentView.bounds;
}];
The above code works as expected. However, if the animation block is reordered to the following then the animation goes haywire (scales massively and center point is off screen):
[UIView animateWithDuration:.25 animations:^{
childView.frame = parentView.bounds; //This line was after .alpha
childView.transform = CGAffineTransformIdentity;
childView.alpha = 1;
}];
What's going on here? Why is the order that the properties are set significant to the animation?
The order of the properties is probably relevant because the frame is undefined when the transform is not the identity transform.
Warning: If the transform property is not the identity transform, the value of this property is undefined and therefore should be ignored.
From the documentation for frame (on UIView).
This is true for getting the frame value but I believe that it also is true for setting the frame.
I'm almost certain that the changes in your animation block happens on the model of the views layer before they are animated on the presentation of the views layer.
Since you are coming form a state where the transform is a scale, setting the frame is undefined.
In your top example the transform is set to identity before setting the frame, thus it works as expected, but in the second example you set the frame before restoring the transform.
To illustrate this question, I gisted a very small Xcode project on Github (two classes, 11kb download). Have a look at the gist here or use git clone git#gist.github.com:93982af3b65d2151672e.git.
Please consider the following scenario. A custom view of mine, called 'container view', contains two little squares. Illustrated in this screenshot:
The blue square is a 22x22 pt UIView instance and the red square is a 22x22 pt CALayer instance. For purposes of this question I want the two squares to 'stick' to the bottom right corner of the outer view, while I animate the frame of that outer view.
I change the container view's frame within a UIView's class method animateWithDuration:delay:options:animations:completion:, with a non-default easing parameter of type UIViewAnimationCurveEaseOut.
[UIView animateWithDuration:1.0 delay:0
options:UIViewAnimationCurveEaseOut
animations:^{ _containerView.frame = randomFrame; }
completion:nil];
Note: Both the blue UIView's and the red CALayer's frame are set in the overridden setFrame: method of the container view, but results would have been the same if I had set the blue UIView's autoresizingMask property to UIView flexible left and top margins.
In the resulting animation, the blue square 'sticks' to the corner just the way I intended it, but the red square completely disregards both timing and easing of the animation. I assume this is because of the implicit animation feature of Core Animation, a feature that has helped me in many occasions before.
Here are a few screenshots in the animation sequence that illustrate the asynchronicity of the two squares:
On to the question: Is there a way to synchronize the two frame changes so that the red CALayer and the blue UIView both move with the same animation duration and easing curve, sticking to each other as if they were one view?
P.S. Of course the required visual result of the two squares sticking together could be achieved in any number of ways, for example by having both layers become either CALayers or UIViews, but the project that the real issue is in has a very legit cause for the one to be a CALayer and the other to be a UIView.
I'm assuming that you got the end position correct and that after the animation that the view and the layer are aligned. That has nothing to do with the animation, just geometry.
When you change the property of a CALayer that isn't the layer of a view (like in your case) it will implicitly animate to its new value. To customize this animation you could use an explicit animation, like a basic animation. Changing the frame in a basic animation would look something like this.
CABasicAnimation *myAnimation = [CABasicAnimation animationWithKeyPath:#"frame"];
[myAnimation setToValue:[NSValue valueWithCGRect:myNewFrame]];
[myAnimation setFromValue:[NSValue valueWithCGRect:[myLayer frame]]];
[myAnimation setDuration:1.0];
[myAnimation setTimingFunction:[CAMediaTimingFuntion functionWithName: kCAMediaTimingFunctionEaseOut]];
[myLayer setFrame:myNewFrame];
[myLayer addAnimation:myAnimation forKey:#"someKeyForMyAnimation"];
If the timing function and the duration of both animations are the same then they should stay aligned.
Also note that explicit animations doesn't change the value and hat you have to both add the animation and set the new value (like in the sample above)
Yes, there are a number of ways to achieve the same effect. One example is having the view and the layer be subviews of the same subview (that in turn is a subview of the outer frame).
Edit
You can't easily group the UIView-animation with an explicit animation. Neither can you use an animation group (since you are applying them to different layers) but yo can use a CATransaction:
[CATransaction begin];
[CATransaction setAnimationDuration:1.0];
[CATransaction setAnimationTimingFunction:[CAMediaTimingFuntion functionWithName: kCAMediaTimingFunctionEaseOut]];
// Layer animation
CABasicAnimation *myAnimation = [CABasicAnimation animationWithKeyPath:#"frame"];
[myAnimation setToValue:[NSValue valueWithCGRect:myNewFrame]];
[myAnimation setFromValue:[NSValue valueWithCGRect:[myLayer frame]]];
[myLayer setFrame:myNewFrame];
[myLayer addAnimation:myAnimation forKey:#"someKeyForMyAnimation"];
// Outer animation
CABasicAnimation *outerAnimation = [CABasicAnimation animationWithKeyPath:#"frame"];
[outerAnimation setToValue:[NSValue valueWithCGRect:myNewOuterFrame]];
[outerAnimation setFromValue:[NSValue valueWithCGRect:[outerView frame]]];
[[outerView layer] setFrame:myNewOuterFrame];
[[outerView layer] addAnimation:outerAnimation forKey:#"someKeyForMyOuterAnimation"];
[CATransaction commit];
If you want David Rönnqvist's snippet in Swift 3.0, here you have it:
CATransaction.begin()
CATransaction.setAnimationDuration(1.0)
CATransaction.setAnimationTimingFunction(CAMediaTimingFunction(name: kCAMediaTimingFunctionEaseOut))
// Layer animation
let myAnimation = CABasicAnimation(keyPath: "frame");
myAnimation.toValue = NSValue(cgRect: myNewFrame)
myAnimation.fromValue = NSValue(cgRect: myLayer.frame)
myLayer.frame = myNewFrame
myLayer.add(myAnimation, forKey: "someKeyForMyAnimation")
// Outer animation
let outerAnimation = CABasicAnimation(keyPath: "frame")
outerAnimation.toValue = NSValue(cgRect: myNewOuterFrame)
outerAnimation.fromValue = NSValue(cgRect: outerView.frame)
outerView.layer.frame = myNewOuterFrame
outerView.layer.add(outerAnimation, forKey: "someKeyForMyOuterAnimation")
CATransaction.commit()
I have an odd problem in one of my chain animations. I have block object for each of the blocks on my screen (26 of them), and when the user presses them I perform a flip. It works great, but I'm adding a scale animation before I do these to make them about 50% bigger on the screen. So, my sequence is:
enlarge
delay (let user see the large image)
spin-out 90% (removes block from view) - using transform.rotation.y
change image & spin-in
shrink.
I have setup the window view controller to be a delegate of these blocks, such that it can pass a counter to the blocks so I can position the right sublayer on the top (using setZposition).
It all works great, except when I have 2 blocks on positioned above/below each other on the screen, such that the enlarge will cause them to overlap, and then when the spin-out animation starts, it immediately has the right side of the block pop behind the block below it. I've tried changing the animation to transform.rotation.x and get the same behavior when the blocks are side-to-side.
I'm not sure if it's an iOS bug of if I'm just not doing something correct. Any suggestions are greatly appreciated. Here is the spin-out method:
- (void)spinOut:(id)sender
{
NSTimeInterval animationTime=0.85;
[UIView animateWithDuration:animationTime
delay:0
options: UIViewAnimationOptionCurveLinear
animations:^{
// setup the animation to spin the current view out
[CATransaction begin];
[CATransaction setDisableActions:YES];
CABasicAnimation *spinOut = [CABasicAnimation animationWithKeyPath:#"transform.rotation.y"];
[spinOut setDelegate:self];
[spinOut setDuration:animationTime];
CAMediaTimingFunction *tf = [CAMediaTimingFunction functionWithName:kCAMediaTimingFunctionEaseIn];
[spinOut setTimingFunction:tf];
[spinOut setFromValue:[NSNumber numberWithFloat:M_PI * 0.0]];
[spinOut setToValue:[NSNumber numberWithFloat:M_PI * 0.5]];
[spinOut setRemovedOnCompletion:NO];
[spinOut setFillMode:kCAFillModeForwards];
// setup variables used to roll in the next view on animation completion.
[pageView.layer addAnimation:spinOut forKey:kMyVeryOwnABCsSpinOutKey];
[CATransaction commit];
}
completion:^(BOOL finished){
[self setFlipOutAnimationTimer:[NSTimer scheduledTimerWithTimeInterval:animationTime target:self selector:#selector(spinIn:) userInfo:nil repeats:NO]];
}];
}
OK - this is an old question, but I kindof figured out this problem. Since I was flipping these images around the Y axis, I was able to change the animated image's Zposition. In my startAnimation method, I added:
float pageLevelLayerPosition;
// logic to set the zposition variable 100 more than anything nearby
_originalImageViewZPosition = bigImageView.layer.zPosition;
[bigImageView.layer setZPosition:pageLevelLayerPosition];
and then when in the animationDidStop, I added the relevant line of code to reset it back to 0 where I was removing the animation. I had some code to manage the variable so that I was assured that the number was greater than anything nearby.
I guess if I ever get into 3-D animation, then I'll need to control this much more closely, but that is what was causing my problem.
My app uses CALayer to draw views. More precisely, it uses the drawLayer:inContext: method on a sublayer of a UIView's top layer. This is a nice way to get the 'implicit' animation of consecutive drawLayer:inContext: drawings to fade into each other over time. The fading animations happen fairly fast, maybe in 0.25 seconds, but to change its duration, simply implement another delegate method called actionForLayer:forKey:. In this perfectly working example implementation here the default duration is stretched to 2.0 seconds:
- (id<CAAction>)actionForLayer:(CALayer *)layer forKey:(NSString *)event
{
CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:event];
animation.duration = 2.0;
return animation;
// or return nil for the default duration.
}
On to the issue at hand.
If you call [sublayer setNeedsDisplay] faster than the fades have time to complete, with each new fade you'll see a sudden jump. From the looks of it, the fade that's in progress is cancelled and it's final state is used as the starting point of the new fade. This might not be very surprising, but the visual result is rather unwanted.
Consider the scenario of a ten second fade from black to white, with another fade, to black, triggered five seconds after the start. The animation will start fading from black to white, but when it's at a 'half way gray' it jumps to full white before fading to black again.
Is there a way to prevent this from happening? Can I get the layer to fade from the gray back down to black? Is there a CALayer drawing equivalent of saying UIViewAnimationOptionBeginFromCurrentState (used in UIView animations)?
Cheers.
A layer's animation is only a visual representation of what the layer should look like as it animates. In CA when you animate from one state to another, the entire state of the layer changes immediately. A presentation layer is created and displays the animation, and when the animation completes the actual layer is left in place at the end.
So, my guess is that when you want to transition from one state to another, and the current animation hasn't completed yet, you have to capture the current state of the animation and then use this as the starting point for your next animation.
The problem lies in not being able to modify a layer's current animation.
In the following post I capture the current state of an animation, set that as the current state for the layer and use that as the beginning value from which to animate. The post applies this technique to the speed / duration of an animation, but can also be applied to your scenario.
https://stackoverflow.com/a/9544674/1218605
I'm a little stumped on this one too.
Did you forget to specify the fillMode kCAFillModeForwards. There's more info about that in the reference docs.
For example, I got this to work without any snapping, although I'm not changing the duration.
#implementation FadingLayer
- (void)fadeOut {
CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:#"backgroundColor"];
animation.fillMode = kCAFillModeForwards;
animation.fromValue = (id)[UIColor redColor].CGColor;
animation.toValue = (id)[UIColor colorWithRed:1.0 green:0.0 blue:0.0 alpha:0.0].CGColor;
animation.removedOnCompletion = FALSE;
animation.delegate = self;
[self addAnimation:animation
forKey:#"test"];
}
- (void)fadeIn {
CABasicAnimation *animation = [CABasicAnimation animationWithKeyPath:#"backgroundColor"];
animation.fillMode = kCAFillModeForwards;
animation.fromValue = (id)[UIColor colorWithRed:1.0 green:0.0 blue:0.0 alpha:0.0].CGColor;
animation.toValue = (id)[UIColor redColor].CGColor;
animation.removedOnCompletion = FALSE;
animation.delegate = self;
[self addAnimation:animation
forKey:#"test"];
}
#end
You'll probably want to animate a custom property however.
Hope this helps :/
I wanted to accomplish the same thing with a zoom animation of a layer tree. I have a zoom in/out key-equivalent where the user can zoom the layer tree accordingly. However, if the user presses the zoom key-equivalent in rapid succession, there would be a temporary snap-back to the values prior to the onset of the animation, since the previous animation hadn't yet completed.
At the end of the animation code, performing a sole [CATransaction commit] forced any pending transactions to be committed to the layer model before the start of the next animation, and solved the problem.
The documentation says:
+ commit
Commit all changes made during the current transaction.
Declaration
+ (void)commit
Special Considerations
Raises an exception if no current transaction exists.
However, testing this with many [CATransaction commit] messages in succession doesn't actually raise an exception. I've used this same technique to squelch warnings of the form:
CoreAnimation: warning, deleted thread with uncommitted
CATransaction;
in an NSOperation whose thread of execution finishes before layer animations do. It could be that Apple changed this behaviour in recent OS releases to a no-op (which would be much saner) if no current transaction exists, without updating the documentation.