I noticed this thing yesterday, and now I'm really worried about it. I tried to draw just one quad on the screen (it is as big as half the window). I'm using a vertex array, triangle strip, no textures (disabled), and ortho mode (3D is even worse). When nothing is drawn, the framerate is 1230. But if I draw that quad here is what I get: -wireframe: 1170 fps -GL_FILL: 1000 fps 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). Is this supposed to happen or am I doing something wrong (perhaps, some wrong settings)? I wonder what would happen if only I dare to draw some more triangles...

It's nothing to worry about.

Quote: Original post by lazork357
When nothing is drawn, the framerate is 1230.
But if I draw that quad here is what I get:
-wireframe: 1170 fps
-GL_FILL: 1000 fps

So at first it takes 0,0008 secs to draw a frame, and after it takes 0,001 secs to draw a frame. That leaves you with a 0,0002 second increase in drawing time. Not that much to worry about, is it?

(example given to emphasis that frame rate is a poor tool for performance measurement, unless you give the values a second thought)

I think the "problem" is generally to draw something on your screen. Almost no matter if there is a single polygon or a complex model to be rendered.

I found out that in my program there are no noticeable differences in the framerate between rendering an object with 10 polygons or rendering an object with about 63.000 polygons.

The problem is that if I draw that quad 10 times (just calling glDrawElements 10 times) my framerate drops down to 370, and if I draw it 100 times it goes down to 50, which is no good at all.
Yet that's just 200 triangles!

But if each one of those triangles is a half of the window then you get 100 screens filled... thats the problem, becouse no real world game does anything close to that...

My worries concern the 2D stuff on screen, rather than the whole world.
And since I'm creating a GUI, I suppose there could be lots of objects covering large portions of the screen.

You should learn about bottlenecks. In your particular case, you should not count the number of triangles you draw to evaluate your performance, but the number of pixels you fill. Your framerate is determined by the slowest element in your renderer, in your case drawing pixels.

Think about it.. you are drawing 100 half-screens every frame, and you still have 50 fps. If has nothing to do with the amount of triangles drawn! According to my calculations, you are drawing more than a billion pixels per second.

Y.

Well, I guess I have to trust you.
After all, you're much more experienced than me.
Thank you all, I'll let you know about the result of what I'm doing.

To try and sum up a few arguments from the various replies so far:

1. FPS is a bad measurement of performance. It is non-linear. SPF (seconds per frame) is a much better measurement. For example the drop from 10000 to 9000 FPS may seem dramatic, but it's equivalent to a drop from 100 to 99.9 FPS, which is very little. Both are equivalent to a SPF increase of 1.11×10^-5


2. Be aware that there are several stages where your program can be bottlenecked. Simplifying slightly you could be using all the processor power available and leaving the GPU idle (CPU limited), pushing lots of vertices through with little computation and no visible output thus leaving the CPU and the GPU->Framebuffer bus idle (Transform limited) or you could be pushing very few large objects and leaving the CPU and GPU vertex/fragment processors virtually idle but leaving the GPU->Frambuffer bus overloaded (Fillrate limited). You're obviously looking at a fillrate limiting situation, which means you can raise complexity in the other areas at little or no cost in speed.


3. 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.

Enigma