The documentation says that the clipsToBounds property of UIView will clip the drawing to the bounds, or more precisely that the subView can't draw outside of the bounds of the superView.
Sounds nice, but what does that mean in practice?
If I set that to YES, then my subView will automatically only draw those parts which are not outside the bounds of the superView. so it increases the overall performance or do I still have to make sure that I don't create any views that are not visible, i.e. inside a UIScrollView ?
I think it's the opposite: turning on clipping hurts performance because it has to set up a clipping mask. I vaguely remember reading this somewhere, but I can't find it now.
The use case for clipsToBounds is more for subviews which are partially outside the main view. For example, I have a (circular) subview on the edge of its parent (rectangular) UIView. If you set clipsToBounds to YES, only half the circle/subview will be shown. If set to NO, the whole circle will show up. Just encountered this so wanted to share.
The (possible) performance hit is only deterministic if you know the view hierarchy. As mentioned above, usually the renderer will use GPU cycles to draw the view UNLESS some view within the hierarchy uses drawRect:. This does not affect OpenGL ES application because drawRect:is omitted in this type of apps.
From my understanding, determining and displaying the clipped area may take less cycles than actually calculating/drawing/blending the whole view. As of OpenGL ES 2.0 clipping can be calculated in GPU.
Related
I'm trying to make sure my UILabel's and UITextView's stay sharp when they exist within a UIScrollView. I came along the 'contentScaleFactor' property on the UIView class, it seems to work perfectly fine on custom drawing but UITextView's and Labels just refuse to redraw themselves at the right contentscale.
http://pastebin.com/PBjhjMbR
Maybe this is due that the actual views that draw the text are a subview of these classes?
You need to set contentScaleFactor recursively on all subviews and also call setNeedsDisplay on each view that you set it on to make them display at higher quality. I have also found that it is not worth setting it on a UIImageView because they won't render at higher quality anyway so there's no point in wasting memory by making their backing layers bigger.
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).
Is it possible to make a UIView only appear inside a limited area of the screen, especially while animating? (When it reaches the boundary, it should simply cut off at the boundary point, as if it were being obscured by an object in front of it.) I need this because I have a roll-out menu comprised of UIButtons, and I don't want the menu to extend beyond the edge of the toolbar when closed. Thank you!
(Alternatively, hiding the entire UIView upon reaching the boundary would also be acceptable. I just don't know how to check for this condition without continuously querying the center property.)
You can define a clipping area for your UIVIew using the clipsToBounds property. If you are using CoreAnimation to animate your view, you may want to have a look a the maskToBounds property of CALayer objects as well (each UIVIew has a layer property of type CALayer).
From the UIView Class reference:
Normally, a subview’s visible area is
not clipped to the bounds of its
superview, but in iOS you can use the
clipsToBounds property to alter that
behavior.
My question is very similar to this one Not drawing outside bounds when clipToBounds=NO which received no clear answer.
Basically I have a UIView, and I want to draw a line from the center of it, to the edge of the screen. Calculating where these points are is easy, using [self convertPoint:(CGPoint){0,0} fromView:[self superview]]; (which finds the origin with respect to my view's superview. But when I draw a line from my view's drawRect: it gets clipped at my view's bounds.
Is there a way to draw outside of my view's bounds? I've tried changing the clipsToBounds property, but it doesn't seem to have any effect.
I can't draw my lines from the superview because I need to do this with multiple views and some will be in front of others... figuring out the layer from the superview's drawRect seems like a bad idea.
Similarly, I don't think I can just resize my view's bounds to include the entire screen, because my views need to be dynamically re-sizable... the bounds would have to be HUGE (>20,000 points square) for this to work.
I wouldn't recommend ever drawing outside of a view's bounds. Either your view needs to resize automatically to include your drawing or you need to have transparent overlapping views. Or both. I can't think of a situation that either of these cases wouldn't cover, but I may lack imagination. =)
Likely what is happening currently is that when the super view gets redrawn it tells the super view that it needs redrawn, resulting in erasing the drawing you are doing outside. It's been a while, anyone more knowledgeable can (should!) correct me here if I'm wrong.
I don't know if "Quartz Debug" (from the standard apple developer tools install, /Developer/Applications/Performance Tools/Quartz Debug) works in the simulator, but it's worth a try. It has a mode that will show you when and how often redrawing takes place, with a border and optional delay on the refreshes.
You can do what you are asking, but you need to force redraw your sub-views every time you go outside the sub-view's bounds, meaning that your super-view needs to manually draw it's children inside of it's draw function. Essentially you would be throwing out apple's drawing paradigm and simply causing your sub-views to act like a drawing extension of your main view anyway.
Additionally, if your ranges are so dynamic you may want to consider drawing in percentages of the screen or super-view rather than in points, it may make more sense to code.
I have a UIScrollView with a custom content view that uses drawRect to display its contents.
In my drawRect method I respect the passed CGRect parameter and only draw what's needed.
However, each time the drawRect is called it is passed the entire bounds of the view, even if it is several thousand pixels, and I'm worried about performance and memory use. Is there any way to make a UIScrollView limit this, or am I worrying too much over nothing?
Also, I've tried using CATiledLayer as the layer, and while this corrects the passed rect, it feels like I'm misusing the class. Also, the view still keeps all the pixels backed as far as I can tell. (Even if it doesn't draw some of them right away)
using CATiledLayer is probably the best option. I'm familiar with CATiledLayer as a concept, but never used it myself, so I'm not going to say anything about that. What I can say, is that if you subclass the UIScrollView and implement
layoutSubviews
you should be able to redraw the subviews toll-free with good performance, as long as you implement a construction using
CGRectIntersectsRect()
In which you can see if the current visible rect, in the case of a subclass
[self bounds]
intersects with the rect of the object you want to draw. if it doesn't, you can choose to ignore the object or even (if it is already on the scrollview) remove it from superview. if it does, you can place the object on superview.
again, CATiledLayer is a way better solution, but if you feel like you are misusing it, try the approach I described.
1.content view large than scrollview is true..
2.may be you should realize UiScrollViewDelegate's
scrollViewDidScroll
caculate content view 's rect that should be redrawed ,not the entire bounds .