If my code is fast enough to produce animation at, say, 600FPS, how does this translate to refresh rate on the video card? If the video card is set to 60Hz or 120Hz, and the code does a glutSwapBuffers() 600 times in a second, how does this translate to how the video card outputs it? Does the video card still “refresh” at the 60 or 120 times? How does OpenGL determine which frames to skip?
With or without vertical synchronisation ?
without vsync (*SwapInterval(0)) :
- all frames are available to the display. For a CRT, you will see 10 horizontal stripes (10*60hz = 600 frames). For LCD, there is so much digital processing that ‘it depends’ but you can still see some of these stripes.
with vsync (*SwapInterval(1)) :
- when calling swapbuffers : the card waits vsync signal to actually swap. So swapbuffer may seem to take a lot of time, enough to go down to 60hz (or 120 depending for a 120hz display). Sometimes, the card can buffer a few frames (more than the API-exposed double buffer), so swap will only block when there are several frames ready for display.
I wasn’t aware that vertical sync affected it. But, after looking at some articles, I understand it a little more (http://hardforum.com/showthread.php?t=928593).
However, I’m unable to find any articles or books that talk about how the video card combined with OpenGL works. Do you have any recommendations??
If all 600 frames are available, what does that mean? Is the video card capable of outputting all 600 frames completely within a second? Are those horizontal lines caused by the monitor not refreshing fast enough? Or is it caused by the video card not being able to copy the buffer quickly enough?
how the video card combined with OpenGL works
Well nothing particular, same as any 2d raster based display since RAMDAC where fast enough for human eye.
May I ask why you want to know more about this ?
Are those horizontal lines caused by the monitor not refreshing fast enough? Or is it caused by the video card not being able to copy the buffer quickly enough?
Both can be bottlenecks.
Imagine we have a CRT (simpler to explain) :
The RAMDAC has a maximum speed, so as it rushes through the frame buffer, converting RGB byte value to analog voltage pixel by pixel, it can not go faster than its limit. For example it may be able to output 120Hz for a 1024x768 display but only 60Hz at 1920x1080.
The CRT has a maximum speed too, as electron beam deviation is done with coils. A sawtooth signal through the coils drive the beam very quickly from the end of the line to the beginning of the next one. That is bad for coils. And it is the original reason for interlaced TV back in the time (less lines to do per second), but I digress.
So the available resolutions and refresh rates are within this range, permitted by both the RAMDAC and the CRT.
As you understood, simple 3D rendering can happen much faster than this refresh rate, ie. 600hz for 60Hz.
Now instead of RAMDAC to CRT, it is TMDS to LCD, all digital communication. Still not as fast as a 3D card ultra high speed bus of course : longer distances, less wires. And LCD imaging has its own limits, such as response time.
Google/wikipedia about these terms for details.
There’s a lot of things I don’t understand about the video card. All of the OpenGL books that I’ve looked at discuss things such as the rendering pipeline, etc. But, I am interested in the limitations of the video card. I haven’t been able to find any resources that go into detail about video cards
Thank you for your explanation regarding the horizontal lines. There are a lot of terms that I’m not familiar with, such as RAMDAC and TMDS. That’s why I was interested in learning about how video cards work.
There is still something I don’t understand, and I think I asked the question incorrectly. If the video card can render 600 fps without vsync, does it draw 600 full frames? Another way to ask is, does it draw the full frame 600 times but the monitor is unable to refresh fast enough, which causes the tears/stripes?
Darn page refresh, I have to rewrite a long explanation
I thought I explained it, apparently not clear enough 
both the card and the screen are physically unable to output images at 600Hz. On the card side, the limitation is due to the RAMDAC, than scans the front framebuffer only 60 times per second, in sync with the speed permitted by the screen, to provide the intensity for each of the red, green, blue beams sweeping the screen line by line :
http://archive.electronicdesign.com/files/31/34510/figure_01.gif
And without vsync, the front framebuffers changes 10 times faster with 600Hz render, so you will see 9 horizontal tears. Each tear line separate two different images.
You see now that this is caused by both the card electronics and the screen limitations ?
Imagine a card with a killer feature, a costly RAMDAC able to output 600Hz ! … too bad no screen exists to actually display that, just “out of sync range”
Then why there are no 600Hz screens ? Because anything past 100Hz is overkill unless you need active stereo.
That makes sense now, lol. You explained it well the first time, I just didn’t connect the dots well enough. Thanks!