I would like to implement a drawing class with the help of Quartz.
I want to be able to save parts of what is drawn on separate layers. I want these layers to be retrievable, so I can delete/hide/show layers on command.
Can I save multiple CGLayerRef as a NSMutableArray property of my class and then be able to retrieve them? If yes, can you point me to an example.
If there are any flaws in the "architecture" above, please point me to alternative solutions that could help me accomplish layered control over graphs.
Thank you.
CALayers that you create, can of course be stored in NSMutableArray, and you can work with them later on, usually by animating their properties, or asking them to redraw themselves.
Usually you create a custom UIView, create and manage layers within that view. Those layers are either member variables of that view, or you store them in an array. As things are happening in your app, your view animates the layers accordingly. Usually you want to react on touch events (which you also implement in that particular view - touchesBegan/Moved...) and animate the layers.
CALayer draws itself and caches the content for as long as you call [layer setNeedsDisplay], or it's bounds (size) are changed (well, if needsDisplayOnBoundsChange is true). Practically in all my apps I did, such redrawing happens very rarely - only if data are changed, and layer needs to redraw. Animating layers, transforming their size, rotation, changing position - layer is not redrawn during any of these. Hiding, showing, changing transparency - no redraw is required.
That "drawing class" you are talking about - you actually have only two options - either you extend CALayer and overwrite drawInContext:, or you create basic CALayer, set its delegate, and there you draw in drawLayer:inContext:. I personally prefer creating delegates.
Related
I've always been told that if you want to display things into a view, you must add subviews into it and then draw into those subviews.
And today, I see that question (searching for something else) : IPhone SDK: Camera access?
In the accepted answer, I see that its author uses CALayers to draw 4 sub "views" into the main view, but all of this only based on CALayers...
So I wonder... Why ? Is this a correct way of doing ? What could lead me to use seblayers instead of subviews ?
I've been using both UIViews and CALayers. It really depends on what you want and need. UIView uses CALayer in the background, so you're using CALayers in either case. Note that there's a layer property in UIView of the type CALayer. However, coding directly with UIView is easier but it doesn't expose the full powers of Core Animation. Coding with CALayer does expose you to Core Animation and a dozen of other APIs.
If you're just concerned adding subviews, either approach would work. You can think UIView hides some of the CALayer implementation details.
What are the differences between adding a view as a subView VS drawing the view in that view's drawRect method?.
I use both approaches, but I was wondering apart from the obvious such as, if you do in drawRect it will be a single View, as opposed as two views, or adding as a subview is just easier. Are there any specific situations where you should definitely use one over the other?
Overriding -drawRect: can be a good way to draw complex UITableViewCells. Having all of the subviews composited and drawn as one view helps table view scrolling performance immeasurably.
Having said that, I typically stick with the highest level API available and drop down to a lower level only if performance suffers.
Adding a subview is easier as you point out, and I really see this as no contest in 90% of cases. You should generally add a subview and let the libraries handle drawing of subviews in their correct position.
I only use -drawRect: to accomplish custom drawing within my view, but not to draw subviews, it creates unnecessary complexity. If you need a lot of performance, -drawRect: can help you there. Also, in the case of simple drawing, -drawRect: is very nice as opposed to making several subviews. But in general, it pays to just add a subview.
If in the future you decide you want these subviews to receive touch events or handle things interactively, it is more difficult to refactor your -drawRect: code.
I've noticed that when animating things in UIKit, certain types of animations can be composited using standard block-based animations while others cannot. For instance, view.transform interferes with view.frame, but not with view.center. Are these things documented anywhere?
On a related note, because of these compositing issues, I've often resorted to animating mainly using CGAffineTransforms, since they can be composited very easily. Is this a good idea? It seems that applying a transform is different under the hood than simply changing the frame, so I'm not sure if I should be using them to permanently move a view or change its size. Do CGAffineTransforms and view.frame-related changes overlap at all?
Thanks!
For what it's worth, here's Apple's stance on this:
You typically modify the transform property of a view when you want to
implement animations. For example, you could use this property to
create an animation of your view rotating around its center point. You
would not use this property to make permanent changes to your view,
such as modifying its position or size a view within its superview’s
coordinate space. For that type of change, you should modify the frame
rectangle of your view instead.
Source: View Programming Guide for iOS, View and Window Architecture
(I suppose one exception would be permanently rotated views, which would be impossible to accomplish with frame modifications.)
I've also determined that CGAffineTransforms appear to modify the underlying rendered image of a view, not its content, so (for example) applying a CGAffineTransformScale is fundamentally different from expanding the frame. I'm not sure if this is necessarily true, or if it depends on contentMode/other factors.
I'm still not entirely clear on how the frame, bounds, and transform of a view interact. You can, for example, set the frame of a view after applying a rotation, and it'll be relative to the rotated view, whereas modifying the bounds will apply the transformation to the view pre-rotation (IIRC).
On iPhone I have a CALayer that I animate via Core Animation. Then at some point I change view controllers. I then return to the view controller with the CALayer and in viewWillAppear: I set the frame and position properties on my layer to move it back to its starting point.
Setting these properties changes the model layer but the presentation layer still has the old values and its presentation layer does not update until the next animation I play.
In the CA Programming guide it says :
"You can query an instance of CALayer for its corresponding
presentation layer while an animation transaction is in process."
Which, to me, implies that the presentation layer should only be different from the model layer during an animation. But there are no animations currently running. I even used kCATransactionDisableActions to ensure that when I set the position property an implicit animation is not started.
Does anyone know why my presentation and model layers are out of sync?
Thanks.
One workaround I've used is to reset the position of my layers in viewWillDisappear. Also I noticed that if I don't animate my layer right away then it does indeed move to the position that I set in viewWillAppear.
It sounds like Apple just uses the Presentation Layer during animations, and has lazy updates to it. When it's not animating, it must use the normal layer. My only bet is this is how they manage to thread the UI and avoid weird errors. It may even be related to which threads are used.
Your problem gives us insight into Apple's hood, perhaps the answer is simply that is what apple is choosing, and it answers a question I had, too.
As far as I can tell, I need an UIView (or subclass of UIView) to display an CALayer on screen, right?
Then, what's the point of using CALayer for saving memory? The only point I see is when I would add several sublayers to a CALayer. Then those sublayers would not get copied 3 times for all the different tree types like presentation tree, render tree and so on. Is that right?
You can add CALayers as sublayers of another CALayer. Each individual layer does not have to be backed by a view, but the root layer in the hierarchy must be backed by a UIView.
The point is not to avoid having copies of the CALayers, which are quite lightweight, but to avoid having copies of UIViews or, more specifically, the graphics contexts that back UIViews. Those take up considerably more memory.