-What is beamsync?
Well, in short words it is a conditional loop (wait state) that waits until a physical screen-redraw starts (until the whole screen is redrawn), to avoid graphics being processed faster than it can be displayed.

-What does this mean?
Well, first we have to take a deeper look into how graphics is treated.

There are two cases:

1. Graphics is treated by the cpu and then transferred to the framebuffer of the
Graphics chipset.
2. Graphics is treated by a graphics card & partly the cpu.

Case 2 is obviously faster, but in either case a technique called double buffering is used (and in special cases more than double buffering).

One draws the graphics in a buffer that is not seen - it is called the logical buffer.
The buffer that is currently seen is called the Physical buffer.

If one was to draw directly into the physical buffer processing intensive situations would yield flickering, due to graphics being drawn slower than the actual update rate of the CRT screen or LCD screen. Therefore, it is smarter to draw graphics in a logical buffer not seen, and then the graphics chip-set lets the logical buffer become physical after graphics processing is done.

Though, to avoid flickering simply using double buffering is not enough, as if the switch between which buffer is logical or physical is not synced to your displays update rate - you will still have flickering. e.g. graphics in the logical buffer has been processed - logical & physical buffer are switched by setting the graphics processor unit to display the logical so that it becomes physical and that while the physical screen redraw of your LCD/CRT is in the middle of your screen-redraw.

So to have flickerfree graphics it must be synced accorting to your respective screens update rate e.g. every 8 ms on a good LCD display. The GPU switches which buffer is to be seen when the screen-redraw has completed i.e. when your screen has shown the last point/pixel on the bottom of the screen, successfully avoiding flicker this way.

-Fuck it, I can live with some flickering, what does that yield?
Well, considering case 1 above, where the CPU waits until the beam has drawn the last pixel on the bottom line of the screen, u get a deasent speed increase - more cpu overhead as that loop is not hogging your cpu.

Considering case 2, where the GPU does most of the graphics processing apart from what cannot be accellerated, you do not get such a massive speed increase but do get a little speed increase, all depending on if the CPU needs to be synced with the GPU.
In certain cases the GPU (graphics processing unit) simply cannot do all the graphics on its own, and the cpu will be hogged with a beamsync test (conditional loop) - yielding less cpu overhead - i.e. when using bitmap fonts - or bitmap data in general, as it is first loaded from disk or created in memory and then processed by the GPU.

-Summary:
In all cases the Graphics chip-set and CPU must work in sync to avoid flickering... and as they do not operate on a 1 to 1 speed basis (the cpu cannot be totally dedicated to calculating graphics if one wants a responsive game forexample), a double buffer is introduced, the more buffers, the less beamsyncs needed as distance in time between processing and physical display of data becomes greater, though if big enough will make graphics less responsive in an interactive application. Not using beam sync yields more CPU overhead.

Graphics engine using beamsync in worst case scenario on a display updated every 8th ms (millisecond) shown in steps:
8ms = 1 VBL (vertical Blank/vertical retrace)

1.Process data in logical buffer while displaying physical buffer. The data drawn is so advanced that the ammount of time used is 1.5 VBL and the beamsync test is performed - no more graphical data is processed, making us lose .5 VBL (4ms), until VBL number 2 is reached, as then step 2 occurs.
2. The previously logical buffer where the new data has been drawn becomes the physical one and vice versa.
3. goto 1

-What happens when the cpu needs to sync with beam in the example above?
In step 1, we have a massive slow-down as the cpu is doing a loop of several instructions for 4 ms... which in the case above ammounts to 1/4 of the processing power / cpu overhead, not to mention that cpu interrupts occur when it needs to do other tasks like reading the keyboard, loading from hard-drive etc...


I hope this document has displayed a few pros and cons regarding beamsync.

I know my english might suck bigtime - but do read it properly instead of asking me 1000 questions.

Regards,

a black belt in beamsyncing that has beamsynced since the 1980´s