Glut and hardware acceleration

I wrote this small and simple opengl application that draws about a hundred squares and rotates them around z-axis.

First I did this using glut to open up a window and so on. Resizing the window at runtime affected fps immediately. Using a smaller window gave more fps and larger window slowed down.

Then I copied the code for opening opengl windows using native Windows calls from NeHe’s tutorials and added this rotational code to it. Resizing the window does NOT affect the fps at all.

Now, it seems like glut doesn’t do the window initialization right in Windows -> it doesn’t use hardware acceleration. Am I right or wrong or did I use glut the wrong way? I have a TNT2 Ultra card if that’s got anything to do with it.

Well, GLUT creates an environment for rendering, and the actual rendering is performed by the driver. If this environment is accepted as a hardware accelerated enviromnent by the driver, hardware acceleration is used. If you let GLUT do the work, or you do it yourself, shouldn’t matter.

In “normal” cases, there shouldn’t be any notable difference between native Win32 API and GLUT (which in turn uses the native Win32 API).

Are you sure you are using the same code for rendering in both programs? Otherwise, one application may be fillrate limited, and the other one geometry limited, and therefore the difference when resizing the window.

I am a beginner with opengl and I don’t even know what do these terms fillrate limited and geometry limited mean

There is something different in NeHe’s code, I don’t remember the exact name, but something like pixelMode? I didn’t do that with the glut version. I’ll check the name when I get home from work.

[This message has been edited by funk (edited 11-28-2000).]

Unless you are doing any fancy tricks when creating windows/pixel formats (doubt that since you said you are a newbie), I see no reason why there should be any difference at all. And as far as I know, NeHe’s isn’t doing any fancy tricks in this area.

Geometry limitation is when you stuff to much geometry (points, lines, triangles) into the rendering pipeline. So much that it is busy processing the geometry before it can be drawn.

Fillrate limitation occurs when you are passing too much large geometry. A card can only push a finite number of pixels through the pipeline at any given time. If you are trying to push more pixels than it can handle, your framerate will drop, because it takes longer to finish the frame.

Fillrateproblems occurs when trying to display loads of large primitives.
Geometryproblem occurs when trying to display very detailed scenes.

And ofcourse, a combination of these two can occur too

p.s. The pipeline, if you didn’t know that either, is more or less the rendering engine (the stuff on the card).