Enigma:
I expecially appreciated your third point.
Even though I should have known it improves speed, I had never thought of redering front to back.
I'd better remember this once I come to 3D graphics

Quote: Original post by Enigma
There are techniques to cut down bottlenecks in each area. To reduce fillrate you can render front-to-back with depth testing enabled (for opaque objects). This ensures that each pixel of the screen will be rendered a minimal number of times and most objects will be depth culled.

Right, except that you should do the contrary for translucent objects !

Quote: Original post by lazork357I'd better remember this once I come to 3D graphics

Depth testing can also be useful in 2D rendering.

(sorry for double posting but the server won't allow me to edit my post)

Quote: Original post by lazork357
I knew it usually takes some time to fill such a big polygon, yet I didn't think of such a fps loss (and wireframe is slow too).

Unless you've bought a "professional" card (say Quadro, NOT GeForce which is rather considered a "gamer" card) you should expect worse performance with wireframe mode than fill mode. Yes, worse. The main reason is that wireframe is not used very much in games, so GeForce-like cards don't optimize it (it goes for Radeon too of course). Assuming you're posting at the gamedev.net forums, forum for game development...

Quote: Original post by lazork357
Is this supposed to happen or am I doing something wrong (perhaps, some wrong settings)?

The only "wrong" thing you're doing is filling the WHOLE screen many times per frame. This usually never happens that much.

Quote: Original post by lazork357
I wonder what would happen if only I dare to draw some more triangles...

As Ysaneya told you, don't take for granted that the number of triangles drawn per second is the only performance level. There are many, many bottlenecks possible. Triangle rate is one of them, but it's not relevant in your case. Fillrate is.

This is where you need to consider clipping algorithms so you only render visible parts of the gui. For instance windows does not even attampt to draw all the windows on the screen at once, only updates the changed portions when they happen. your gui should do the same. Also never draw things that are not visible. Why woudl your gui need so many large objects on the screen at once? you would never see them all at once.

I've already considered clipping, but since I want my GUI to be semi-transparent (or at least I want to allow this), I can't avoid to draw the windows (or other elements) on the background.
About drawing only the changed portions, I wouldn't know how to do that: how can I avoid the drawing of the unchanged objects? If they have to be on the screen they have to be drawn every frame (yes, I need to clear the screen for other reasons), or am I wrong?

This is just another case of permature optimization.

translucent windows lose there use quite quickly, so you should not have too many problems with the iser wanted them for every window fullscreen.

i have an idea, code the gui, and worry about optimization after you understand how things will fit together and are working. you can test and decide if limits need to placed on how windows are handled.

If windows XP can handle translucent windows and still be usable, i cant see why your gui cant do the same. When was the last time you honstly used 100 fullscreen translucent windows in XP? When you see user doing that, then you can worry about performence for your app.

And no unless they are partially visible, the window does not need to be drawn. What exactly are you trying to do with this gui?

I didn't notice anybody mention this (I just skimmed through), but using a vertex array for something with few vertices (say, <10) may actually slow down your performance. I found that drawing a skybox using manual glVertex3f() calls was twice as fast as calling a display list, and a vertex array may be very similar in that regard.

What Cryoknight says is interesting.
Yet, I wouldn't be so sure about that.
Actually, I don't think that sending all my vertices one by one is faster than sending them in one array.
Arrays can become slow if you dynamically allocate them every frame, but that's not my case; I know it's one of the worst things to do.

Now, about what the Anonymous Poster said;
I've already coded my GUI once and I'm rewriting it all, both to improve its functionality and its performance. So, as you see, optimization does matter.
What exactly am I trying to do with this gui? Well, I don't know yet, and this is why I want it to be as flexible and versatile as possible.