I am loading a number of UIViews onto a UIScrollView and am trying to track down why they are using so much memory. After a process of elimination using Instruments I have discovered that setting the background colour of the views increases memory usage by 4 times.
If I don't set the background colour the memory usage sits at around 4.5megs. As soon as I set the background colour to anything redColor or clearColor the memory usage jumps to 17megs.
Here is the code:
ThumbnailView *thumbView = [[ThumbnailView alloc] initWithFrame:CGRectMake(0.0f, 0.0f, 225.0f, 320.0f)];
thumbView.tag = aCounter;
thumbView.backgroundColor = [UIColor clearColor];
Does anyone know what could be causing this?
What I am really after is to have the background clear. If there is no way around this, is there another way of setting the background of a UIView to be clear?
All instances of UIView (and classes derived from it) have an associated CALayer object (accessed via the layer property) that provides the UIView's visual appearance. The CALayer can have it's own bitmap, it can share a bitmap with another CALayer object (which is how reflections are done), or it can have no bitmap.
When a UIView acts as a container for other controls, it has no bitmap associated with it's layer, thus it uses very little memory. As soon as you set it's background colour, that backing bitmap has to be created so that there is something to render. If the UIView subclass implements drawRect to draw some graphics into the view, the same thing will happen.
Because a full-screen sized view consumes a lot of memory, when you implement a UIScrollView based solution, you should only load the views that are displayed and the two either side. Don't create loads of them in advance.
Related
Currently I have a horizontal UIScrollView populated with UIViews. The views are dequeued when moving off screen and reused. Each UIView is subclassed to draw images using drawInRect with [someView setNeedsDisplay] being called when the view enters the screen.
[_image drawInRect:imageRect];
My gradients, text, shapes, etc all load smoothly but as soon as I draw an image I suffer a noticeable performance hit. The size of the image doesn't seem to matter because the scroll view always lags. (I get the same result when using a UIImageView as well.) All of my images are loaded beforehand too.
Is there a better way to draw images that won't result in poor performance?
If you're just drawing images, you might consider using CALayers with CGImageRef contents—drawRect: overrides are going to be slower than CALayer compositing. Another thing to watch out for is alpha-blended images, which require frequent recompositing, or images that aren't aligned to integral pixels. The Improving Image Drawing Performance on iOS tech note is a great place to start on this kind of thing. Once you have the basics in hand, the Core Animation instrument in Instruments will be of great help to you—it watches out for blending, copied images, misaligned images, and screen updates.
I have a custom view for which I've (in the XIB) created a UIImageView as a subview. How can I make the image view appear in the background? (i.e. so that in the custom view I can create the hands of a clock that will appear over the top)
Do I need to make my background image have alpha areas for transparency? (if I have the terms correct) Or is it OK to have an image with it's background just set to white or black or whatever it needs to be (on the basis it will be in the background so this will be ok)
You can't: views are composited on top of their superviews, which means if your custom view is drawing in -drawRect:, it will always appear under the UIImageView.
The easiest way to achieve the effect you're looking for is to put the image view under your custom view in IB.
Background images generally do not need to have transparency (and there's a slight speedup if the PNG has no alpha channel).
An alternate approach to using UIImageView objects if you are drawing the rest of stuff in drawRect: is to use the image directly. Draw the image in drawRect: before you do any of the drawing.
Example
- (void)drawRect:(CGRect)rect {
[backgroundImage drawInRect:rect];
/* Do rest of your drawing */
}
Now this is only if you are using a complex image. If it is a texture, you would rather use UIColor's colorWithPatternImage: method to get a color from the UIImage object and set your custom view's backgroundColor. Remember that using the colorWithPatternImage: will not scale the image while drawing and will tile if the source image is smaller the frame of the view.
I want to display so many images in table cells. I knew two methods to show an image.
One is creating an instance to UIImageView and show it
CGRect rect=CGRectMake(x,y,width,height);
UIImageView *image=[[UIImageView alloc]initWithFrame:rect];
[image setImage:[UIImage imageNamed:#"sample.jpg"]];
Another method is,
CGRect rect=CGRectMake(x,y,width,height);
[[UIImage imageNamed:#"sample.jpg"] drawInRect:rect];
Now, my question is, what is the difference between these two? Which one is efficient? Or someother function is available better than this?
Thanks in advance....
Using the drawInRect: method has CoreGraphics draw the image into the active CGContext using the CPU. Assuming you're in a UIView's drawRect: method, this will paint the image into the view's buffer.
UIImageView uses whichever image is assigned to it as it's backing buffer instead of using the slower drawRect:. The GPU then references this buffer directly when the screen is composited via QuartzCore.
UIImageView is a UIView subclass. By adding it to the view hierarchy you get all the free benefits: animations, size properties, affine transoforms, etc. Plus, you are able to change the underlying UIImage any time you want.
On the other hand, calling drawInRect: will just draw the image where you tell it to, but not interact with the UIView hierarchy, so you don't gain any of the benefits from having it on the view hierarchy.
I would think (have not tried it), that drawing the image directly is faster, but I would think in most of the cases having a UIImageView is a better idea.
I have a UIView with a large number of CALayers (~1000), each of which has a small image as its contents. This UIView is a subview of a scrollview (actually it's a subview of another view which is a subview of the scrollview). This draws relatively quickly at first (couple seconds). However when I scroll in the scrollview the frame rate is very low.
Is it trying to redraw the contents of each CALayer every time I scroll? Is there a way to disable this? Is something else going on?
Note: I set clearsContextBeforeDrawing to NOo n my UIView and this helped somewhat but it's still much slow than I would expect
The layers should not be redrawn, but they will be composited using the GPU. Try using the Sampler and OpenGL ES instruments in Instruments to see if your bottleneck is in the CPU or GPU. You can log extra detail within the OpenGL ES instrument by tapping on the "i" next to the instrument name and selecting the extra parameters (Tiler Utilization, Renderer Utilization, etc.). If one of the OpenGL values is near 100%, then it's the compositing that's holding you back. However, if the sampler is showing a number of calls to -drawRect: or similar methods, then your layers are being redrawn (for some reason) and that could be the problem.
Additionally, you can use the Core Animation instrument to color non-opaque layers, which can lower your display framerate.
Set the needsDisplayOnBoundsChange property on your layers to NO:
[layer setNeedsDisplayOnBoundsChange:NO];
All,
I'm having trouble getting behavior that I want from CATiledLayer. Is there a way that I can trigger the tiles to redraw without having the side-effect that their areas are cleared to white first? I've already subclassed CATiledLayer to set fadeDuration to return 0.
To be more specific, here are the details of what I'm seeing and what I'm trying to achieve:
I have a UIScrollView with a big content size...~12000x800. Its content view is a UIView backed by a CATiledLayer.
The UIView is rendered with a lot of custom-drawn lines
Everything works fine, but the contents of the UIView sometimes change. When that happens, I'd like to redraw the tiles as seamlessly as possible. When I use setNeedsDisplay on the view, the tiles redraw but they are first cleared to white and there's a fraction-of-a-second delay before the new content is drawn. I've already subclassed CATiledLayer so that fadeDuration is set to 0.
The behavior that I want seems like it should be possible...when you zoom in on the scrollview and the content gets redrawn at a higher resolution, there's no blanking before the redraw; the new content is drawn right on top of the old one. That's what I'm looking for.
Thanks; I appreciate your ideas.
Update:
Just to follow up - I realized that the tiles weren't being cleared to white before the redraw, they're being taken out entirely; the white that I was seeing is the color of the view that's beneath my CATiledLayer-backed view.
As a quick hack/fix, I put a UIImageView beneath the UIScrollView, and before triggering a redraw of the CATiledLayer-backed view I render its visible section into the UIImageView and let it show. This smooths out the redraw significantly.
If anyone has a better solution, like keeping the redraw-targeted tiles from going away before being redrawn in the first place, I'd still love to hear it.
I've found that if you set levelsOfDetailBias and levelsOfDetail both to the same value (2 in my case), then it only redraws the tiles that are touched by my setNeedsDisplayInRect: call, as you'd hope.
However if the levelsOfDetail is different to LODB, then any calls to setNeedsDisplayInRect: redraw all the tiles.
You could add another layer (possibly a CATiledLayer) behind the existing tiled layer. (Sort of a double-buffered solution.) You would call setNeedsDisplay: on the second layer from a timer that fires after a few seconds to ensure that that layer doesn't redraw at the same time as the front layer.
Another potential option is to use the same delegate to draw content to a bitmap context and swap the bitmap into the backing store once the content is refreshed. This should produce a flicker-free result. That being said, I can't tell you how this might be done, and one nice thing about CATiledLayers is they automatically generate tiles when you zoom and pregenerate tiles when you pan once zoomed in.
I would like to see how you implement your application. I have been looking for weeks to find an example that uses a combination of UIScrollView and a CATiledLayer-back view with a lot of custom drawn lines. Apple has some great sample code - but it all involves images rather than line art, so no help for me.
Having read through these answers without a solution, I discovered that tiling a page was the dominant background task.
Preparing my lo-res placeholder image on a high priority queue solved this issue - the images now appear while the tiling is occurring. Caching the placeholder images further improves their appearance - they appear before the tiling begins.
With newer devices, the tiling it so fast, these tricks might not matter. A sample PDF consisting of large scanned images (e.g. a scanned book) tiles the slowest in my experience, and makes for good test data.
I had the same problem with iPad.
The solution was more simple than I thought and far more simple than using UIImageView to render display before redrawing... :
Just don't set any background color for the Layer!
I had CATiledLayer set in a similar way:
layer = [[CATiledLayer alloc] init];
layer.masksToBounds = YES;
layer.contentsGravity = kCAGravityLeft;
//layer.backgroundColor = [[UIColor whiteColor] CGColor];
layer.tileSize = CGSizeMake(1004.0, 1004.0);
layer.levelsOfDetail = 16;
layer.levelsOfDetailBias = 8;
Note that I have commented out the line setting layer's background color to white.
After that the white blank before redraw problem disappeared!
Let me know if anyone has tried that.