Is that an very cost-intensive function that sucky my performance away under my feet? I guess they used that one for the waggling buttons on the home screen + core animation. I just want to know before I start wasting my time ;)
Seems unlikely that it'd be much of a performance problem - it works out to something like a Cosine, a Sine, and a few multiplications. Don't call it thousands of times a second, and you'll be fine.
Very (very) little. This is also something you can easily measure yourself; see the following URLs for examples/information on implementing high-resolution timing:
http://developer.apple.com/qa/qa2004/qa1398.html
http://code.google.com/p/plinstrument/source/browse/trunk/Source/PLInstrumentTime.h
http://code.google.com/p/plinstrument/source/browse/trunk/Source/PLInstrumentTime.m
http://code.google.com/p/plinstrument/
Like with everything, it depends on how and how much you use it. It's used all the time in game development, which the iPhone is very well suited for. CoreAnimation is also very fast. If you're worried about it, my suggestion is to take one of the Apple-provided sample apps and run it through Instruments to preform some of your own benchmarks to see if they are acceptable for your needs.
All CGAffineTransformMakeRotation() does is fill in the matrix for a regular old CGAffineTransform. If you think you can fill (or pre-fill) the matrix faster yourself, then go for it (I'd be really surprised if this wasn't super-optimized already).
Then when it comes time to do the actual work of applying the transform, I'm pretty sure the GPU is told to take care of it so it'll run fast and your main CPU shouldn't take too much of a hit.
If you're really worried about it, then do the transforms in 2D space on top of OpenGL to make sure it's hardware optimized.
I just want to know before I start wasting my time
Optimise the system not the individual lines. Who knows how many times your code will call the transform. Better to get the whole system working, profile it and then optimise the parts that are too slow.
Don't worry about individual calls that people tell you are slow. Use this information as a pointer if your code is slow but always see how the operate in your code.
Related
I recently chose to switch to a method where my library is totally empty and I embed every image/animation/sound that I need via the Embed tag because it would make my life easier. Having a lot of symbols in my library causes CS5 to run extremely slowly and it was really annoying me.
This was totally fine for making games for computers but I'm currently working on my first iPhone game and I'm noticing that the game starts lagging after a few seconds of play. It's not even a complex game but it does have a lot of images with transparency. So I'm wondering if it would run faster if I forget about the empty library method. I don't really know how that would affect performance but this is the first time that I have to worry about performance. But I am aware of other things that affect performance like transparency and object pooling (just read about this one).
Also the exact same game runs worse on an iPad even though it's a more powerful device?
Having images in your library means that Flash will compress them when it exports the SWF/SWC. This may or may not be desirable.
Using the [Embed] tag means that you can compress them yourself in something like Photoshop and have complete control over the output.
You say that your "game starts lagging after a few seconds of play". This seems to be a memory/design problem rather than whether or not your images are embedded through code or as library symbols. Do some profiling to see where you're spending most of your time, and to check that you don't have a memory leak.
Both using the library and the [Embed] metatags influence performance of your IDE, but they are evaluated at compile time and will produce just about the same byte code.
The performance of your game at runtime is an entirely different issue, though you might be able to get good results by rethinking which images to embed as bitmaps and which to use as vector sprites, how to organize larger images (e.g. creating one basic player sprite and adding individual looks by composition, instead of making each player variation a full sized animation) and trying to reduce the use of transparency and alpha masks.
There are many good articles about improving ActionScript performance both on the AVM2 and on iOS devices. Try searching for "ActionScript optimization runtime" - it should yield plenty of results.
I'm building a UIView with a custom drawRect function. This is a fairly complex view, with a number of different items that need to be drawn. I've basically broken it down into one function per item that needs to be drawn.
What I'm wondering is should I pass my CGContextRef, obtained from UIGraphicsGetCurrentContext(), as a parameter to each function, or can I just call it at the start of each function? The latter option looks neater to me, but I am wondering if there is much of a performance penalty?
It's the same, unless you are saving/restoring context all around. In any way, getting the context from that method will, most probably, never be the bottleneck.
I suggest that if you are not saving and restoring states, you could use the UIGraphicsGetCurrentContext(). However, if you are indeed saving state, you should pass this one since it would be easier to read your code.
It's a matter of style I guess...
Pier-Olivier's response is good, and just grazes the key issue: don't worry about it until you have to. This is a case of premature optimization. Before spending a lot of time deciding whether to pass around your CGContextRef, you should write your application and then look at the performance. Using Instruments can help you figure out where your real bottlenecks are. If it turns out this is causing problems (which I highly doubt), then you can optimize it.
just profile after it's implemented correctly and well tested.
if it really shows up as a hotspot, then your problem is likely best divided, and/or rendered to an offscreen context... or by using lower level rendering.
This is kind of weird, but I noticed that up to 40 percents of the rendering time is spent inside glAlphaFuncx. I know that alpha testing is very expensive, but the interesting thing is I do not use it :) No single place of code uses alpha testing, neither do I invoke this function in any other way.
I also checked GL layer for blending on other sorts of stuff which might cause this to happen but it is what it is.
So, if anybody knows what might cause glAlphaFuncx to appear on the performance trace of CPU Sampler, I would be glad to hear it :)
Update: fixed the screenshot link: http://twitpic.com/2afxho/full
Update 2: the function that leads to invokation of glAlpaFuncx contains a single line:
[context presentRenderbuffer:GL_RENDERBUFFER_OES];
Update 3: I tried setting the breakpoint inside this function, but it seems it haven't been invoked at all. I guess profiler is screwed up here...
It's weird that this function appears on a profiler trace, as you say you aren't using it. Try setting a breakpoint in glAlphaFuncx to see from where it is being called.
But anyway, that should not be a problem, glAlphaFunc will just set a state in the GL server side, it doesn't (or should) do any more processing than that. It shouldn't be a performance problem, maybe it's a bug in the GL implementation or in the profiler.
To be sure, you can disable alpha test with glDisable(GL_ALPHA_TEST).
From what I can see, glAlphaFuncx could just be taking the hit for setting up the rendering or pushing the pixels. It could be that it is run either first or last in the rendering.
Do you have an actual performance problem, or are you just trying to find pieces of code to slice off / optimize?
If so, you should set a breakpoint in glAlphaFuncx and see where it is called from and why. To do this, just bring up the debugger console and type "break glAlphaFuncx".
Have you tried explicitly disabling the use of alpha channels?
glDisable(GL_ALPHA_TEST);
http://www.khronos.org/opengles/documentation/opengles1_0/html/glEnable.html
Regardless of system, this sort of behaviour -- time spent presenting what's been drawn -- almost always indicates that the GPU is the bottleneck. Either you are drawing too much (if the framerate is a problem), or the CPU isn't doing enough (if the framerate is fine).
Actually, there's one other possibility -- that the amount of GPU work is fine, but the system is waiting for some kind of vertical retrace period. (That seems unlikely on a device that only ever has an LCD, and doesn't support a raster scan display, but maybe things still notionally work that way internally.) The upshot is still the same as far as the amount of CPU works goes, though, in that you've got time to do more stuff without affecting the frame rate.
I can't explain exactly why glAlphaFuncx specifically is appearing in the call stack, but if it doesn't appear ever to be actually getting called then I'd consider it a red herring until proven otherwise.
Specs: about 320 x 270 px, 5 seconds. I don't know exactly how many images needed for a fluid animation, but let's assume 30.
What would be the best way to playback this? As a movie file in some kind of quicktime view (if available), or as an animated image sequence with UIImageView? I'm not sure but I believe loading 30 images per second is nearby impossible on the ipod touch. Any idea?
In general, a movie will have applied some compression and possibly even used a lossy compression. This means the processor would need to work harder but it has a lot less memory to read. The CPU is a fast resource. Compared to the CPU, memory is slow. Thus a compressed movie would (logically) have the better performance.
In practice, it could depend on a lot of factors, although movies do tend to be better optimized for animations. With a slow CPU and extremely fast memory, a multi-image animation might just be faster. Also, it depends on how you store those many images. But in 99% of all situations, movies will have better performance.
Well, I guess it depends.... if it supposed to be static, than a movie is the most appropriate way... it's hardware accelerated, and easy to write the code for using it. If you plan to modify the animation, and reuse it, you could load and modify images, or load a bunch of them in succession, but I imagine it's quite coding overkill for the task.
Why would you not want to use a video file? If you don't have very specific reasons, I would recommend just using the standard video playback functions provided by Apple.
This gives you several advantages:
Even if your proposed method would run fluidly, it certainly wouldn't be as well optimised for the graphics chip and therefore use up more battery
It's very easy to implement, whereas your idea would be rather complicated, and you'd spend a lot of time on a probably less important part of your app.
It's won't introduce any new bugs and is most likely a lot better tested than your custom solution.
Check out this to get started:
http://developer.apple.com/iphone/library/navigation/index.html?section=Topics&topic=Audio%20%26amp%3B%20Video
I'm programming an puzzle game for iPhone using openGL.
There Is one very weird "bug" ( I'm not sure what It is)... whenever I touch the screen a great number of times in a short period of time my app closes, without giving a warning or error.
What could be the cause ?, I guess It has something to do with the memory, but I would like to know.
Edit:
I also think this happens because I'm calling multiple functions every time the user touches the screen or moves his fingers.
Sounds like you're running out of memory.
A few quick tips that might help out:
Check your memory profile over time using Instruments. If you see a steady incline over time, it's likely to be a memory leak, or an inefficient algorithm that is allocating more memory than you need.
Use a static analyzer to help check for leaks, such as Clang.
Images and image-related files are particularly memory-hungry, so focus on efficiency for them. When you work with textures in OpenGL, use the PVRTC format, which offers awesome compression.
didReceiveMemoryWarning: is your friend - aka a good chance to throw out anything you don't absolutely need in memory. Better to be memory-efficient the whole time, though.
Try setting up an NSUncaughtExceptionHandler. You may also want to setup a signal handler.