Im just wondering what would the best way to display multiple instances of a small (10x1) image. I have an array of about 480 points and I would like to draw the image at each of these points to draw path. Would it be faster to use Core Graphics or should I be using something like cocos2d?
It depends on whether you need it to animate. Core Graphics is probably fine if you are drawing it once and then displaying it as an image, but it it will be really slow if you need to redraw it each frame.
UIKit is actually much quicker because UIView drawing is hardware accelerated, so you could just add a UIImageView for each point in the graph, but from my own experiments that will probably be too slow for realtime interaction if there is more than about 200 image views (at least if you want it to run on anything older than an iPhone 4S).
If you do need realtime performance, that really only leaves OpenGL, which is quite fiddly to set up unless you use a library like Cocos2D or Sparrow to simplify it. I'd suggest Sparrow for your purposes because Sparrow views can be used in a regular UIKit application, whereas Cocos2D provides a whole app framework and is harder to use for just a single view in an otherwise regular UIKit app.
http://www.sparrow-framework.org/
Without more context, another option is to use OpenGL and create a display list for the composite image.
Related
I'm developing an app that must show one of three shapes(UIImageViews) depending on which button the user taps. I'm achieving this by creating different UIImageViews with three UIImages. I was wondering, is it more efficient if I draw the shapes directly from code??
BTW, the images have transparency and are 342 px x 388 px. Thanks!
It depends on the shapes. I suggest using PNG image files unless you are having particular speed issues. This lets the designers/artists customize the look easily rather than making the programmers do it in code, which is more tedious to modify.
We have some nice gradients and shadows in our application and drawing them using Quartz was pretty slow -- fine for a single screen, but too slow when animated or scrolled.
I'm creating an interactive e-book for the iPad. This book will contain multiple pages that will consist of a lot of animations (frame and motion animations), transitions,... I was wondering what my development options are, should I use OpenGL, Quartz,...?
I've use UIImageView.animationImages before and found that it had really bad performance. What's the best way to draw frame based animations?
Does anybody have some good pointers to resources on this?
thanks in advance,
Thomas
I guess that depends a bit on what you'll be drawing. If you have a need for 3D, then OpenGL is the way to go, but it doesn't sound like it. I have a feeling Quartz2D is going to be just fine for your 2D drawing needs. I've done drawing with both and they have a very similar API. I think the downside of using all the raw power of OpenGL is that you have then signed up for doing most of the work yourself. I don't recommend attempting to using Core Animation high level APIs to manipulate OpenGL views.
If you do use Quartz2D and "normal" UIViews instead of OpenGL/EAGLView, then you can take advantage the many pre-canned animations Apple already build with Core Animation. This include the card flip left/right, resizing, moving (x/y translation), rotation and the ever popular e-book page curl.
The best example of iBook like custom page curl functionality I could find is this example code from High Caffeine Content. However, you don't have to bring that much math to the table if you just want to use the out of the box Core Animation stuff. The bad performance you may have encountered could have been due to anything, including older/slower hardware. They have revved the graphics chips on the new devices.
I'm writing a game that displays 56 hexagon pieces filling the screen in the shape of a board. I'm currently drawing each piece using a singleton rendering class that when called to draw a piece, creates a path from 6 points based of the coordinate passed in. This path is filled with a solid color and then a 59x59 png with an alpha to white gradient is overlayed over the drawing to give the piece a shiny look. Note I'm currently doing this in Core Graphics.
My first thought is that creating a path everytime I draw is costly and seems like I can somehow do this once and then reuse it, but I'm not sure of the best approach for this. When I look at the bottlenecks with Shark, it looks like the drawing of the png is the most taxing part of the process. I've tried just rendering the png overlay or just rendering the path without the overlay and both give me some frame gains, although removing the png overlay yields the most frames.
My current thought is that at startup, I should render 6 paths (1 for each color piece I have) and overlay them with the png and then store an image of these pieces and then just redraw the pieces each time I need them. Is there an effecient machanism for storing something you've drawn once and redrawing it? It kinda just sounds like I'd be running into the whole drawing pngs too often thing again, but maybe there's a less taxing method that does a similar thing...
Any suggestions are much appreciated.
Thanks!
You might try CGLayer or CALayer.
General thoughts:
Game programming on iPhone usually necessitates OpenGL. Core Graphics is a bit easier to work with, but OpenGL is optimized for speed.
Prerender this "shiny look" into the textures as much as is possible (as in: do it in Photoshop before you even insert them into your project). Alpha blending is hell on performance.
Maybe try PVRTC (also this tutorial) as it's a format used by iPhone's GPU's manufacturer. Then again, this could make things worse depending on where your bottleneck is.
If you really need speed you have to go the OpenGL route. Be careful if you want to mix OpenGL and Core Animation, they can conflict.
OpenGL is a pain if you haven't done much with it. It sounds like you could use Core Animation and make each tile a layer. CA doesn't call the redraw again unless you change something, so you should be able to just move that layer around without taking a big hit. Also note that CA stores the layer in the texture memory so it should be much faster.
Some others have mentioned that you should use OpenGL. Here's a nice introduction specifically for the iPhone: OpenGL ES from the Ground Up: Table of Contents
You might also want to look at cocos2d. It seems to be significantly faster than using CoreAnimation in my tests, and provides lots of useful stuff for games.
Pretty new to iPhone / objective-C.
I have an application that has 15-100 small images (16x16 or 8x8 PNG) on the screen. For this example sake, let's assume that I can create these images using CGContext if I needed to.
I would have to assume that iPhone would perform better using that method rather than loading images (PNG's). However, the bitmap version is easier to develop and also has other advantages (like built in touch events) that I need.
If performance is not the ultimate metric for this application, does placing 100 small images degrade performance/memory enough to even consider switching to the CGContext method. My instinct tells me that I will not see that much of a performance difference either way but I am too new to iPhone development to know enough about it to make a difference.
I suppose it depends on the complexity of your image generation algorithm.
I will also depend on you application: will you be drawing this images many times per second, like in an animation? If that's the case, use UIImageViews.
I think using 100 or so UIImageViews should be fine as long as you don't need to rapidly animate them or update them at the same time. You should avoid doing anything that would change the size of the views (like resizing the view that contains them all), and if you use Core Animation to animate them, perform all of the animations inside a single animation block. (Wrap everything with one [UIView beginAnimations:context:], [UIView commitAnimations] - not one for each view)
Good luck!
I'd try the bitmap version first, then CGContext one if bitmap is too slow.
THEN if it's still too slow, I'd put all the icons into a GL texture.
I'm considering re-writing the menu system of my iPhone app to use Open GL just to improve the smoothness of scrolling a big image (480x1900px) across the screen.
I'm looking at doing this as a way to improve on using the method/solution as described here (Smoother UIView). This solution was a big improvement over the previous implementation but it's still not perfect and as this is the first thing the user will see I'd like it to be as flawless as possible.
Will switching to OpenGL give me the sort of smooth scrolling I'm looking for? I've stayed clear of OpenGL until now as this is my first app and core animation has handled everything else I've thrown at it well enough, would be good to know if this alternative implementation is likely to work! thanks
You should be using CATiledLayer for images that big. From the UIView docs:
Regardless of which version of iPhone
OS is running, you should consider
using a CATiledLayer object if you
need to create views larger than 1024
x 1024 in size.
Bill Dudney posted the CATiledLayer example from his Core Animation book on his blog. Unless you're building a graphics intensive game, you shouldn't need to drop down into OpenGL. Core Animation should give you all of the performance you need.