I am implementing a UItableView with custom cells.
My custom cell has a UIView inside of it.
I am trying to draw extensive CoreGraphics shapes with gradients in the UIView and I am running into scrolling performance problems -- since the customcell's UIView is getting drawn upon everytime the cell gets displayed.
Are there ways where I could do this differently (such as say, some kind of lazy drawing, drawing asynchronously, UIView caching, preventing the cell from redrawing etc) so as to improve performance?
Deeply appreciate any help, inputs, insights.
The idea is not to compute your graphics every time at draw time, but to render it offscreen in a UIImageView. Then your cell only has to blit the image, which is as fast as can be.
You can still compute your images lazily and asynchronously. The structure of your code could be similar to the Apple sample code LazyTableImages. Google for it. In that sample code, what's slow is not the drawing time, but the network loading time, but that difference is not significant.
Related
I am rewriting a pretty large drawing program, now that Xcode uses Storyboards for Cocoa apps, and was just confused about a few things regarding optimization.
Let's say I have a drawing program where the user can draw different shapes (rectangles, triangles, circles, stars; etc) onto the NSView (Subclass: MyDrawing). Cleary these shapes' points will have to be saved in an array for drawRect to recall for later so that they don't get cleared, However I noticed that the more shapes there were DrawRect/Core Graphics really bogged down and when resizing shapes, it was very laggy.
What would the best practice in this sort of thing be? Should I create a separate class for each shape? Should I create a new NSView for each shape? (Although the second one doesn't make much sense to me)
All I did before was invoke the drawinRect method to update certain parts of the NSView, but found that it was still a little slow.
What is the best most optimal way be to go about drawing multiple shapes (while letting the user edit them later on) ?
I suggest CALayer's inside NSView.
I am drawing a graph with UIKIT and I want to show before it is finished a preloader (spinning circle)
Another solution should be before start drawing set the alpha of my view to 0.0 and when it's done fade it to 1.0.
Someone did this before and/or know how to do this?
If using UIKit, you could draw the path, fill and stroke, then draw another path. This is resource-intensive as you will be calling drawRect: often.
The other way is to create animation. I'll let someone else as I have no experience in creating animation in iOS.
You could add an activity indicator to the view, send the view setNeedsDisplay and remove the activity indicator at the end of the drawRect:, but I doubt you will see the activity indicator at all. Activity indicators are only useful when you are performing some lengthy operations, taking at least several seconds to complete. If drawing the graph is that long, you should either optimize it or consider drawing it on a secondary thread into a CGImage. In the latter case, I'm afraid, you restrict yourself to Core Graphics.
I'm making a game using UIView.
I use a large (8192x8192) UIView as the map area, (the game is birds-eye-view) with a UIImageView stretched across it displaying a grass texture.
This uses heaps of memory, doesn't run on older devices and nearly crashes Xcode whenever I try to edit it...
Is there an alternate method of creating a 8192x8192 map, but without being laggy?
If it's possible to tile your graphics, something involving CATiledLayer would probably be a good fit. CATiledLayer allows you to provide only the images that are necessary to display the currently viewable area of the view (just like Maps does).
Here is some example code for displaying a large PDF.
I have several UIButtons on a UIScrollView. I want the buttons to have rounded corners, so I call maskToBounds: on each of them. When I do this and run on the device, the scrolling framerate is pretty bad (it works fine on the simulator). Any ideas on a workaround for this problem?
You're causing the view to be composited offscreen with that call to masksToBounds:, which slows things down quite a bit. Are you rendering custom button images? If so use UIImage -stretchableImageWithLeftCapWidth:topCapHeight: with an image which is the minimum width to encompass it's rounded edges. This allows the GPU to handle stretching the image in the most efficient way possible, while still giving you a button made out of an image. There is a session in the WWDC 2011 videos on Drawing in UIKit - watch that, as it addresses exactly this problem, and a few others you're likely to have.
A few alternative methods:
Tweeties implementation of fast scrolling, by drawing everything manually
Matt Gallaghers implementation of custom drawing. This is the method I use, as it's easy to maintain
I know that the CGContext cannot call it to draw directly, and it needs to fill the drawing logic in the drawInContext, and call the CGContext to draw using "setNeedsDisplay", so, I designed a cmd to execute, but it cause some problems... like this :
Why I can't draw in a loop? (Using UIView in iPhone)
I think the CGContext is very different from my previous programming experience....(I used HTML5 canvas, that allow me add more details, after I draw, so do the Java Swing)
Actually, I want to know what is the suitable to implement these kind of thing in Apples' programmer mind. Thz.
There are three approaches to what you're asking. You can draw everything in drawRect:, you can manage multiple layers, or you can draw in an image. Each has advantages, but first you need to think correctly about the problem so that you don't destroy performance.
Drawing happens constantly. Every time anything changes, there may be quite a lot of drawing that has to be done. Not the whole screen usually, but still a lot of drawing. Since drawRect: and drawInContext: can be called many times, they need to be efficient. That means that you don't want to do a lot of expensive calculations, and you don't want to do a lot of useless drawing. "Useless" means "won't actually be displayed because it's off screen or obscured by other drawing."
So in the usual case, you put your actual drawing code in drawRect:, but you do all your calculations elsewhere, generally when your data changes. For example, you read your files, figure out your coordinates, create CGPaths, etc whenever your data changes (which should be much less frequent then drawing). You save all the results into ivars, and then in drawRect: you just draw the final result. So in your loop example, you would probably have an NSArray of images in your view object, and in drawRect: you would draw them all in order.
Another approach is to create a separate layer for each image, set the image as the content, and then attach the layer to the view. You're done at that point. There is no more drawing code you need to write. Quartz handles layers very efficiently, so this can be a very good solution to a wide variety of problems.
Finally, you can composite everything into an image, and then stick that image in an image view, or draw the image directly in the view, or attach the image to a layer. This is a good solution if you have very complicated drawing (particularly using CGPath). This can be expensive if you're constantly changing things, since you have to create a new image context, draw the old image into the new context, draw on top of it, and then create a new image from the context. But it's good for a complicated drawing that doesn't change often.
But you're correct, CGContext is not like a canvas. It needs to be redrawn every draw cycle. You can do that yourself, or you can use another view object (like UIImageView) to do it for you. But it has to be done one way or another.