OpenGL and Core Graphics efficiency / performance

I want to pass in a position on screen and test to see if that is within predefined area's of the screen, and if so return an unsigned int relating to the reference of that 'area'.

So I had thought that I could use CGPoint - to represent the position on screen, and CGRect - to represent each 'area', and then use the CG method 'CGRectContainsPoint' to tell me if the position is in the specified 'area'

However, if I didn't have these Core Graphics methods, I could always do it by hand...

I would imagine that CGRectContainsPoint() does something very similar to the code that you've listed below. That being the case, writing the same code locally will be quicker because it saves you a function call, and all the associated parameter passing. But it is incredibly unlikely that such a tiny performace difference unless the code is called with high regularity (is it collision detection code?) it will not make any actual difference.
Using CGRectContainsPoint could be said to be more efficient because it takes up less space in your executable (but again, to tiny a change to make any real difference) and because you are less likely to make a typo in it then spend four days trying to debug the resulting odd behaviour.

The CGRectIntersect would be called ALOT as it will be in the collision detection code, however, the CGRectContainsPoint would only be called when a touch is recognised.

I'm trying to come up with very reuseable means to handling touches in OpenGL Games - which I've been told not to use views for each openngl touchable object.

So having a class that handles the detection against predefined areas and confirms a 'hit' or not - I thought it would make things easier and more extendable.

But you're saying it's better to handle everything locally - yes, I can see that function calls and parameter passing would possibly make a performance drop - even slight. But in a game every little helps right...

Well, it seems to me that if you wanted your code to be faster, that function would not really help much. In making Gravita, I thought the drawing code was what took so long. Weeks after I started optimizing every little thing and not getting results, I found the most obvious bottleneck.

â€œWe should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.â€ - Donald Knuth

As Duke mentioned, don't bother trying to optimize something early on unless you are quite certain that it is going to be a bottleneck. That said, using bounding boxes for your broad phase collision detection (I think that's what you meant when you said high pass?) very well might turn out to be a performance problem, but not because you would be using CG functions.

Collision detection is normally broken down into several phases:Broad Phase: Finding out which objects to collide against other objects. The simplest method is to check collisions with every object against every other object. This is very fast when you have small groups of objects that you want to collide against each other (< 10 we'll say), but extremely slow when you have a lot of objects (< 1000). The reason is that for 10 objects you would need 45 mid-phase checks and for 1000 you would need 499500. It doesn't scale to large numbers very well, and when you have a lot of objects you'll spend more time doing mid-phase checks than anything else. To speed up the broad phase, you'll need to use a smarter algorithm such as sort and sweep, spatial hashing, quadtrees, or some other spatial index that only tries combinations of objects that are likely to be colliding.

Mid Phase: This is where you normally do a simple collision check such as a bounding box or bounding sphere check because they would be faster than your narrow phase. Most spatial index structures are going to return some false positives, and it's best to catch them early instead of calling the more expensive narrow phase collision routines.

Narrow Phase: The narrow phase is the most specific and most expensive collision detection check such as a polygon to polygon check or a pixel to pixel check. A lot of games do just fine with bounding spheres or bounding boxes and don't need a more specific narrow phase check.

Before embarking on implementing a complex broad phase collision detection strategy, just keep in mind what your needs are and don't waste time on something you don't need. I would be willing to bet that NES or SNES era games didn't implement any fancy broad phase detection. Most games only had a handful of enemies on the screen at once and forgot them as soon as they went off screen. They also minimized checks by having objects collide against specific other objects. Fireballs only collided with enemies, and enemies did not collide with other enemies. Write your game, then profile to figure out where the bottlenecks are when it starts getting slow.