What is the fastest and most accurate way of doing GUI rendering with OpenGL? Should I go for blitting (using SDL), or for textured quads? There are a few issues I'm wondering about: 1. does the gfx card need to do a major, costly state change to enter a special mode in order to do blitting? The GUI will be for a 3d game. 2. is blitting, once state change is done (if any), significantly faster than rendering quads? By the way, does OpenGL support blitting directly, or will I have to do this with SDL? 3. are the floating point errors for GUI rendering ever large enough that I will notice any different result than I wanted? Especially if I render with point sampling and pre-made fixed size icons and stuff? 4. any easy way of, with quad rendering, expressing coordinates in pixel coordinates during rendering? How about glVertex3i and similar, for example? 5. if I do quad rendering, would I gain much performance by storing the quad coordinates in a VBO, vertex array or display list, then use a matrix transform to give it the correct size before each render call (or will the state change needed to set up a matrix cost more or almost as much)?

Quote:1. does the gfx card need to do a major, costly state change to enter a special mode in order to do blitting? The GUI will be for a 3d game.
2. is blitting, once state change is done (if any), significantly faster than rendering quads? By the way, does OpenGL support blitting directly, or will I have to do this with SDL?

I have no idea how you'd go about using a blitting mode in OpenGL (well, except that it probably involves grabbing the front buffer and manipulating it directly, or writing to a texture then rendering that texture as an alpha'ed quad over the scene), and I don't have any numbers to back up my statements, but I'd wager quite a bit that except in certain pathological cases, blitting is going to be significantly slower than using textured quads.

Quote:3. are the floating point errors for GUI rendering ever large enough that I will notice any different result than I wanted? Especially if I render with point sampling and pre-made fixed size icons and stuff?

Again, there are pathological cases where they might conceivably make a difference, but for the most part, no.

Quote:4. any easy way of, with quad rendering, expressing coordinates in pixel coordinates during rendering? How about glVertex3i and similar, for example?

Easiest way is to, when you want to render your GUI -

1. Save the current modelview matrix.


2. Set the modelview matrix to a plain vanilla orthographic projection such that the coordinate system maps directly to screen pixels in a manner fit to your liking.


3. Render your textured quads as you want them to appear on the screen.


4. Restore the saved modelview matrix.

Quote:5. if I do quad rendering, would I gain much performance by storing the quad coordinates in a VBO, vertex array or display list, then use a matrix transform to give it the correct size before each render call (or will the state change needed to set up a matrix cost more or almost as much)?

VBOs and vertex arrays are only really going to give you a performance gain if you use them to batch all your GUI elements into a single draw call. If you do this, then you won't be able to use matrix manipulations to move them around. Realistically, though, you're not going to be able to fit them into a single draw call because you'll probably need to change the texture state a couple of times, because you'll be using a couple of textures.

Using matrices to move the quads around is only really going to give you a performance gain when each GUI element is complex enough (over hundreds of primitives, at least) to make a difference. For 10-20 primitives, it really doesn't make a difference.

A VBO is only going to give a performance gain over vertex arrays when the vertex data is static; if you're updating the coordinates of things every frame you'd need to restream the data into the VBO, so you'd best case end up with the performance of a vertex array anyway.

tl;dr, I think this is a pretty solid case of premature pessimisation. GUIs aren't really graphically-intensive things; there's no reason to spend a lot of time optimizing them until you need to.

Quote:Original post by Mushu
A VBO is only going to give a performance gain over vertex arrays when the vertex data is static; if you're updating the coordinates of things every frame you'd need to restream the data into the VBO, so you'd best case end up with the performance of a vertex array anyway.

Not true! A VBO will, in many cases, save you an extra memcopy, because the driver determines the memory destination instead of it having to be in your app's memory space. I would put it the other way around: Vertex arrays, at best, perform as well as VBOs.

@Mushu: I think SDL supports blitting... maybe this is the wrong forum to ask about that :). It seems quad rendering is sufficiently good though, judging from what I read here. I just want to make sure I optimize it as much as possible without resorting to bad OO design, to save as much computation performance as possible for my 3d world :)

Quote:Original post by all_names_taken
@Mushu: I think SDL supports blitting...

It does, but using SDL 2D functionality on top of OpenGL is a No-No, there is a 99% chance it wont work, and if it does, you're on your own.

The closest you can do is blit to offscreen SDL_Surfaces and then map them to textures and then render a quad textured with said SDL_Surface.

Ok!

nice avatar :)