3D Rendering Theory

Posts: 33
Joined: 2002.04
Post: #1
I have a few questions on rendering theory for the wise ones. Answers are nice, but resources are welcome too.

If you sync to VBL and are running fast enough to meet the number of frames per refresh rate, is double buffering still required to prevent display errors?

Does the sync to VBL block the rendering thread and if so when? Does it work differently for full-screen / windowed mode?

Quote this message in a reply
Posts: 5,143
Joined: 2002.04
Post: #2
you always want double buffering. Not to prevent display errors, but for performance.

VBL sync blocks in SwapBuffers if and only if there are no more free buffers -- that is, you've previously swapped one or more frames that haven't made it to the screen yet.
Quote this message in a reply
Posts: 1,234
Joined: 2002.10
Post: #3
It does work differently between fullscreen/windowed modes.
If you use a fullscreen attribute in your pixel format (and capture the display like a good citizen) the framebuffer layout can be reconfigured and the swap can be done with hardware pageflipping. That is, just changing the start address of the framebuffer.

In a window, you're always rendering to an offscreen buffer, which then has to be copied to the correct position on the screen when you swap (possibly clipping or blending depending if other windows/overlays are obscuring your window.) This is always slower than fullscreen, but is still pretty fast with today's many-gigs-per-second hardware.

The VBL difference comes in when you consider that in a window, there are potentially many other applications all fighting for updates. And in 10.3, the ATI drivers aren't very good at handling that, so the VBL doesn't always work (for example, obscuring your window with a drop down menu breaks VBL sync.)

In fullscreen, you own the display, other apps don't interfere.
Quote this message in a reply
Posts: 17
Joined: 2005.05
Post: #4
Quote:And in 10.3, the ATI drivers aren't very good at handling that, so the VBL doesn't always work (for example, obscuring your window with a drop down menu breaks VBL sync.)

I always wondered why it does that. I though it was a bug in the window server (like it was causing a flush) but its a driver bug... So now I can blame ATi when my openGL application goes funky when you run the mouse over the dock (when the openGL context is behind the dock) or open a menu over the window.

Quote this message in a reply
Posts: 3,591
Joined: 2003.06
Post: #5
It happens with my NVidia card too, so I've been under the impression that it was the OS.
Quote this message in a reply
Post: #6
I would think that if you have sycnhronization to the vertical blanking period, and you do your screen swap immediately after the verticle blank, ie so that you are behind the redraw of the screen display but not moving ahead of it, then you won't see any flicker from the screen flip. The only time you get anomalies and flickering stuff is when the rendering to the visible screen crosses paths with where the `beam` is that actually creates the image on the physical screen, either going past it or back behind it. Then you get a `tear` in the display, which you notice usually when you aren't synching to the vertical blank. The other reason to have double buffering is so the user can't see what you're drawing as it's being drawn, given that you are drawing it slower than the refresh rate. If you can draw faster or as fast as display's Hz rate, you can get away with single-buffering if you are careful not to get near to where the beam is drawing.
Quote this message in a reply
Post Reply