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.
Related
A client sent me an email saying that he noticed his computer was sluggish, and when he ran diagnostics he determined the cause was that his webpage was using up a bunch of CPU. In trying to debug why his site might be using so much CPU on his computer, I noticed while using Chrome that nothing was happening in the Console, but that in the Timeline, there is an unending loop of "Recalculate Style, Update Layer Tree, Composite Layers" despite nothing happening on the webpage.
Screenshot of timeline: http://i.imgur.com/kW6CedU.png
I tried searching how to determine the cause of this, and found that Canary might help, so I tried the Timeline in Canary and didn't see anything different.
I've read it can be from CSS transitions being written as transition:all instead of the actual property that needs to be transitioned, so I changed all instances of transition:all in the CSS to a singular target (transition:height for example) and still this loop continues.
I'm also not certain that this loop is what is causing his CPU to be taking a hit, but it's my best guess. I noticed that the website constantly had the "loading" circle animation in the window's tab for Chrome, but now it's not doing that anymore. I'm not sure if it's because I changed the CSS transition rules that it isn't constantly "loading" now, nor am I sure it has anything to do with the CPU usage.
Any advice appreciated.
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.
What does the error warning: check_safe_call: could not restore current frame usually indicate? I've read in other places that it's a memory issue. Is it always a memory problem?
I'm getting this error on the device (not the simulator). NSZombieEnabled shows nothing. If I Build and Debug, my debugger window shows nothing. The peak memory isn't that high (3MB). It just crashes with the same error every time after scrolling around a map.
Any ideas how to debug this? Thanks.
Edit: I added the reason for my crash in an answer below (creating too many SQLite connections). If anyone else gets this error and finds their solution, please post it below. It seems like an error message with multiple causes.
I've seen this a few times, but never been able to actually pinpoint it to a problem outright. Although, the times I've seen it usually there has been some kind of infinite loop or recursion gone wrong and the debugger will catch it. I don't know if you've left it long enough, but after a while, the debugger should start to load the stack frames it does have and display them in the debugger window. There you should be able to see what is going wrong.
Like I said, usually when I've seen this its been due to infinite loops or recursion and the debugger will show upwards of 5000 calls to the same function, so finding the problem shouldn't be too difficult - but, saying that, it may not be the exact issue.
Just my two cents.
This warning also may happens when to use stack based block out of the scope the block defined without copying it.
http://developer.apple.com/library/mac/documentation/cocoa/Conceptual/Blocks/Articles/bxUsing.html#//apple_ref/doc/uid/TP40007502-CH5-SW2
http://www.friday.com/bbum/2009/08/29/blocks-tips-tricks/
I came accross this problem too but I found that it was caused by an image that was at too high a resolution. It would work perfectly in the simulator but not on the device. I resized the image to 320x480 pixels at 180 pixels per inch and now it works perfectly.
Hope that helps
I found the error in my code. It turns out that the SQLite database I was using was causing the crash. I was forgetting to close my database connection, and each time the code hit a particular function, I'd open a new connection. Eventually there were too many, and the app crashed.
It's looking like a lot of these errors are to do with a kind of overload (as Jasarien says).
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.
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.