I'm using CALayers to display a couple images. I do so by creating the layer and setting its contents property to a CGImageRef. I do not set a delegate on my CALayer.
The layer displays fine, but when another layer moves on top of the first layer, the lower layer's contents are "erased." I'm assuming the CALayer is calling the default delegate and drawing nothing. How do I make my CALayer persist its contents?
Thanks.
The lower layer should not be erased by adding a new layer on top. My guess is that the lower layer is being covered (and thus obscured) by the layer you've added. Try making the new layer smaller than the original layer as a test.
Note that if you call certain methods like setNeedsDisplay on a layer, it WILL cause the layer to discard it's contents.
Do you have any code that might be forcing the layer to redraw? (Like calling setNeedsDisplay, as mentioned above.) That would cause the symptom you are seeing.
Related
In Apple's Core Animation documentation, it says there are two rendering paths involved. From what I know, CALayer caches bitmap data of a UIView content. There are two ways of providing content of a CALayer. One is implementing drawRect: or other CALayer drawing methods, the other is setting a bitmap to the property contents of CALayer.
Here I'm wondering, what happens behind the scene if neither of the above two things is done? I believe there is a private drawing path UIView uses in this situation. What is this private drawing path consists of? How does it work?
The crux of CALayer is that it's GPU-backed. In modern graphics and animation, you want to minimize the number of times your bitmap data crosses between the CPU and the GPU. These operations are costly.
CALayer always uses a private drawing path, whether you use setContents: or drawRect:. In fact, the underlying plumbing of CALayer handles both of these in essentially the same way. When you setContents: , CALayer takes the image you gave it, and uploads it to the GPU via OpenGL (probably nowadays Metal) calls. When you drawRect: the CALayer gives you a context into which you can draw, and then it does the same thing with the bitmap data.
If you don't set contents or implement drawRect, you can still do things like set the layer's background color, border, corner radius, etc. This is being rendered by CALayer's GPU-based private drawing path.
CALayer does not draw any of its content using drawRect:. Only view based drawing techniques like Core Graphics use drawRect: but the only problem with this ways of things is that it is done on the CPU and the main thread making it an expensive process. So instead, Core Animation manipulates a cached bitmap of your apps content in the graphics hardware directly which is far much more optimised. You update or provide the initial contents for a Core Animation layer through one of its delegates (displayLayer: or drawLayer:inContext) or using the contents property as you have mentioned. All layer objects in Core Animation are derived from CALayer.
CALayer is simply a layer object belonging to Core Animation which in itself is simply a support system for UIView or subclasses of UIView. Core Animation is not a drawing technology in the sense it cannot create primitive shapes like Quartz, Open GL ES and Metal can. Instead, Core Animation allows you to manipulate an already existing view and it does this by caching the bitmap data of a UIView and sending this off to the graphics hardware to be manipulated. We say Core Animation is a support system and all its work relies on using layer objects of which CALayer is the main type. It can only do this of course if a view has a layer and a view does not actually need a layer to exist. However, in iOS all views come with a layer attached by default. We say views in iOS are "layer backed". In MacOS, you need to actually add Core Animation support for views.
The actual drawing of the contents of a CALayer happens in a few ways. The first is changing the contents property of the CALayer as you have mentioned and you do this by giving it a CGImageRef. The second is by implementing or overriding in a subclass the CALayer delegate displayLayer: which creates a bitmap and sets it to the content property of a layer. The third is by implementing or overriding in a subclass the CALayer delegate drawLayer:inContext which creates a bitmap, creates a graphics context to draw into that bitmap, and then calls your delegate method to fill the bitmap.
In iOS we do not usually worry about how the content of our view's layers are rendered. Since all views are layer backed, iOS manages how to render these views in the most efficient way possible using the methods I've just described. This is an optimisation to save you time and it makes layers very easy to use. You'll usually worry about overriding these delegates or subclassing them if you are developing for MacOS where views are not always layer backed. You might also worry about this if you decide not to use the default CALayer in iOS, for example you might change a view's layer from CALayer to CAMetalLayer. Or perhaps if you are looking for a performance optimisation and even this in a small number of cases.
There are three ways to provide content to a layer.
- Assign an image object directly to the layer object’s contents property.
- Assign a delegate object to the layer and let the delegate draw the layer’s content.
- Define a layer subclass and override one of its drawing methods to provide the layer contents yourself.
If we don't implement drawRect: or setting the contents property or subclass the layer, it will use the default way which is the second one to provide content to a Layer-backed views's layer. The layer will capture the content of the view and render it.
let flyRight = CABasicAnimation(keyPath: "position.x")
flyRight.toValue = view.bounds.size.width/2
flyRight.duration = 0.5
flyRight.fromValue = -view.bounds.size.width/2
flyRight.fillMode = kCAFillModeBoth
flyRight.beginTime = CACurrentMediaTime() + 3.4
password.layer.position.x = view.bounds.size.width/2
password.layer.addAnimation(flyRight, forKey: nil)
My question is: how is it possible that before I am adding the animation, I first put the layer at the end position, but when the app goes up, I don't see it there before the animation starts? Instead, the animation works after 3.4 seconds as expected.
I mean, how iOS knows that first it needs to run the animation and only then put the layer to it's final position?
This is because there is a presentationLayer and a modelLayer so animation show and modify presentationLayer, so presentationLayer is like a ghost.
You probably know that UIView instances, as well as layer-backed NSViews, modify their layer to delegate rendering to the powerful Core
Animation framework. However, it is important to understand that
animations, when added to a layer, don’t modify its properties
directly.
Instead, Core Animation maintains two parallel layer hierarchies: the model layer tree and the presentation layer tree.
Layers in the former reflect the well-known state of the layers, wheres only layers in the latter approximate the in-flight values of
animations.
Consider adding a fade-out animation to a view. If you, at any point during the animation, inspect the layer’s opacity value, you
most likely won’t get an opacity that corresponds to what is onscreen.
Instead, you need to inspect the presentation layer to get the correct
result.
While you may not set properties of the presentation layer directly, it can be useful to use its current values to create new
animations or to interact with layers while an animation is taking
place.
By using -[CALayer presentationLayer] and -[CALayer modelLayer], you can switch between the two layer hierarchies with ease.
you can find more info here https://www.objc.io/issues/12-animations/animations-explained/
I hope this helps you
It has to do with the way UI changes get applied. When you make a change to a UI object, that change is not rendered to the screen until your code returns and the event loop runs.
When that happens, the system moves your view to it's final position, but then the ACTUAL view/layer hierarchy gets covered with a new layer that's drawn on top, known as the presentation layer. The presentation layer is where the pixels from the animation show up on the screen. That's what you see.
When the animation finishes, the presentation layer is hidden/removed (not honestly sure which) and the actual layer contents are shown. At that point the layer is in it's final position, so everything looks correct.
I'm animating an ImageView using CABasicAnimation.
I move its layer to left, right, up and down and sometimes I'd scale it bigger then reset it to its original size etc.
I'm doing all this to its layer so I thought I might have to move & scale the real thing along with its layer as well but when I tested it with tap gesture to see if it really was just staying where it started, it wasn't. Therefore I no longer need to change its view's frames as far as I'm concerned.
Is changing a view's layer's values also change its view's values?
A UIView is no more than a fancy wrapper for a CALayer – bringing UIResponder events & animation conveniences among many other things.
Many UIView properties are actually just forwarded versions of the underlying CALayer properties, defined purely for convenience.
A view's frame & bounds properties should always reflect the layer equivalents.
transform is slightly more complex, as for the view it's of type CGAffineTransform – whereas on the layer it's CATransform3D. If the layer's transform can be represented as a CGAffineTransform, then you'll be able to access it from the view after setting it on the layer. If it can't be represented, then its value is undefined.
Therefore yes, you are right in saying you don't need to update the frame or transform on the UIView when changing it on its CALayer. Although note that these properties won't reflect the 'in-flight' values of the animation – you'll need to access the layer's presentationLayer for that.
Also note that as #par & #jrturton mention, if a layer's transform is not the identity transform, then the frame is undefined and you therefore shouldn't use it.
Here is the iPad Simulator with four nested UIViews, drawing a custom background, and an inner UILabel. I am rotating the top UIView's CALayer, by getting it's layer and setting transform with a rotateY CATransform3D, animated on a separate thread (but the changes to transform are being sent on the main thread, naturally):
Note- this animation does not loop correctly, hence it appears to bounce.
The layers do animate as a whole, but curiously, the first child and it's descendants appear to be floating above the UIView with the transform applied!
The UIViews themselves are children in another UIView, which has a red background. There are no other transformations being applied anywhere else.
The positions for each UIView were set using setFrame initially at the start.
What is causing this strange behaviour, and how can I ensure the child UIViews transform with their parent, giving a flat appearance to the surface as a whole?
Well. Perhaps unsurprisingly I was doing something silly, but since I'd not used CALayer transforms before, I didn't know if things were acting up. I had overridden layoutSubviews on the UIViews I was creating, and the act of rotating the CALayer was triggering this call and then pushing the child components frame around, due to a bug.
The problem is that CALayers don't actually do 3D perspective by default. In order to do that you need to make a minor change to the layer's transform (which is of type CATransform3D)
You want to change the .m34 field of the transform to a small negative value. Try -1/200 to -1/500 as a starting range. If I remember correctly it should be the negative of 1 over the image height/width.
Change the .m34 property of the layer that you want to appear to "come off the page" and rotate in 3D. When you do that the Z setting of the layer does matter, and will both make closer layers bigger and also make layers that are further away disappear behind other things.
I suggest you do a Google search on "CATransform3D m34" for more information. There is a fair amount of information on the net about it.
So I just discovered QuartzCore, and I am now considering to replace a UIImageView containing a bitmap with a UIView subclass doing things like
CGContextFillEllipseInRect(contextRef, rect);
They would look exactly the same: the bitmap is just a little filled circle.
The very view I'm replacing is playing an important role in my app: it's being dragged around a lot.
Question: performance wise: should I bother? I can imagine that the vector circle is being recalculated all of the time, while the bitmap is just buffered. Or that the vector is easier to digest than a bitmap.
Can anyone advise?
thanks ahead
All UIView's on iOS are layer backed. So drawRect will only be called once and you will draw to the CALayer backing the view. You can have it draw again by calling setNeedsDisplay. When you are dragging the view around and drawing it, the view will render from the layer backing. Using a UIImageView is also layer backed and so the end result should be two layer backed views. The one place where you may see a difference is in low memory situations when the view is not visible (though I am not sure).