It seems that all Nvidia drivers post 28.80 cause image tearing. Im looking for volunteers to verify this. I have included my sample code and config details in the zip file /*sorry about the file extension *.zip this is the format the server requires*/. My program draws a sweeping vertical line and the swapbuffers is told to execute on the vertical retrace so I should only see an image tear when the render time of the graphics card exceeds the 60hz refresh 16.6667msec. It is my belief that the drivers (post 28.80) are running some random code segment every so often which causes this render time to exceed 16.667msec (about 1 out of 20 frames or so). The result, my line tears on my program. More importantly this is universal and all images displayed on an NVidia graphics card will show this tearing as well(when running drivers post 28.80). Or so i think.....

you will probably have to get the glut-3.7 stuff from:http://www.opengl.org/developers/documentation/glut/
I tried shrink down my glut dir but max attach file size here is 100k er so. sorry. Look out for the Mesa lib calls in the Makefiles.
took me a while to get that solved.

Nah, you just need the GL/glut.h file, and libglut installed. Then, compile with gcc -o hello hello.c -lglut -lGLU -lGL -L/usr/X11R6/lib -- that works just fine, no need for the full glut source install.

But I don't see any tearing... what am I looking for? The output is simply various iterations of:

Thanks for the tip on how to compile that stuff easy.
That 1050962054.632581: delta = 29.924989 output
was code i added so i knew how long the render time was
between frames when a drop frame occurs in milliseconds. The actual tearing to look for is in the vertical sweeping line which will look something like this:

The tear in this example is beween 1st three lines and the last 3 lines. The tear in "hello" is a bit more subtile but it is there none the less (on all the computer's i have tested so far anyway, redhat 2.4-18kern dual ppro, gentoo 2.4.20kern P4). On all tests it seems to occur about 2/3s the way down the screen
and not constant, it comes and goes but you should be able to see it about 3-4 times per sweep (often enough not to be waiting arround for an error).

The bar is moving fast b/c you need to have the following environment variable set:

"export __GL_SYNC_TO_VBLANK=1" /* for bash */

You can type that from the bash command prompt to set the variable.

This will tell the computer to swapbuffers on vertical retrace rather than rendering at max speed or swaping buffers when as soon as its done rendering. I tried to mention that in some of the README stuff but it was badly written and done in a hurry, sorry. Set that environment variable and it should slow the line down to a reasonable speed. If you slow it w/ some kinda usleep er somthing, it wont be swaping on the vertical retrace(it will swap whenever), and you will defininitly see the line tearing(which might be a good experement so you know what the image tearing effect looks like). but running sync to vblank is supposed to eliminate this image tearing altogether (unless rendertime exceeds 16.67milliseconds, 60Hz or 13.8msec for 72hz ect.)

THe __GL_SYNC_TO_VBLANK=1 is what we use specificly to prevent image tearing on our realtime application for flight sims.

again, thanks for taking time to look at this. Since most people dont care about a little image tear, I believe this bug has gone unnoticed.

Ah, you're right -- I had that set originally, then didn't when I rebuilt it the second time.

Setting it does slow the bar down, but I (unfortunately) still don't see any tearing at all. The bar does "stutter" once in a while (i.e. a single frame gets skipped), but this doesn't cause any tearing, just two frames with the bar in the same place.

Could I get a copy of your setup files(see if i have errored in some way):
XF86Config, XF86config.0.log, kernel vers, what driver yer using, ect. Wonder if its in my compiler some how? Are you using GART or NVIDIA's agp stuff?

The tearing is usualy only a few pixels wide. Wonder if speeding up the sweep would make it more obvious. Asuming its there and you dont see it, but its not like its really hard to see either so im guessing your right (/me shruggs).

As far as the jumping goes, thats normal b/c hello doesnt get exclusive access to the cpu, other progs like crond tones of windomanager apps will wake everyso often and cause that. just moving the mouse arround can do it too. To reduce this we usualy just run "X" no winmanager and kill all processes that we dont need (fakeing a realtime os, b/c we dont like the realtime linux)