The idea of changing rendering contexts probably isn’t going to be particularly fast. wglSetRenderContext probably isn’t the fastest operation, certainly not something designed for real-time apps.
The only advantage of the second method over the first is that you have to change the projection matrix. It’s more obvious exactly what you are doing (and therefore easier to code) if you use glOrtho, but you won’t have the overhead of changing the projection matrix. How slow that operation is remains in question though. I’d go ahead and use glOrtho for now, and if you have any problems with speed, switch to the second option.
What about if you change to a 2D projection with glOrtho then draw a use a blended textured transparent quad right up over the whole screen.
I’m doing a 2D texture mapped volume rendering app where I have a series of images (slices) that I texture map onto blended quads so you only see the texture, not the underlying quad. That way I’m getting a 3D representation of the image slices.
I’ve often thought if I was to do an app with an HUD that I could use a texture over the whole viewport. I think I may have the idea from other posts on these boards (don’t remember exactly). Depending on the amount of drawing you have to do for your HUD, it could reduce a lot of function calls. Just means you’ll have to use a drawing package to design your HUD - shouldn’t be hard though.
Ortho or frustum, there is no difference !?! both produce a matrix, and they cannod be handled individually (or does the hardware know what the matrix represent ?)
so for a fast hud you have to turn of depthtest(HUDs are always visible), and ortho is a bit easier to use !