OSDev.org

I was planning on putting an option to do double buffering in a graphics library type thingy but how exactly should i go about doing it or should i even support it

like is there even a use for it, i heard of it somewhere being used but i can't see a use for it

Double buffers are almost always used in everything that requires rendering and sometimes triple buffering. Which was the solution for realtime drawing into video memory without creating hmm I forgot what they call it.. out-of-vsync effects. What happends if your drawing into a primary surface that gets displayed without waiting for beginning of vertical retrace, insted they use a offscreen video memory buffer to draw into before switching the displaying buffer.

I think GUI for kernel that uses vesa modes rather then text modes should use the double buffer scheme to prevent those unwanted out-of-vsync artifacts. But I'm not exactly sure how this is done hardware level, I just have some knowledge about opengl and directx that seems have great simularities. But generally the GUI for kernel will have exclusive access to the video memory and some sort of other interface and API is required for hand off the video memory to users. So if you plan to allow users to gain direct access to video memory, which would require a bit more complex design which you may never end up finishing your library. In my opinion I wouldn't go into it until the OS has a need/ready for it.

I currently use a single buffer system and I didn't really see the reason for another since it is all clear with no artifacts and the only slightly double buffer'd thing is my text-based window system thingy


but what about the alogrothim thingy
like i guess you write buffer2 to buffer1 and then video memory

i just don't see the point of that to me its just an extra memcpy

Hi,

Double buffering is where you write to a buffer, and then copy that buffer to display memory (rather than reading/writing directly to display memory).

Jordan3 wrote:but what about the alogrothim thingy
like i guess you write buffer2 to buffer1 and then video memory

That is triple buffering - it sounds like you already do double buffering.....


Cheers,

Brendan

If you have the same sprite for example moving across one side of the screen to the other at some consistant frame rate, without double buffers it will garantee that you have artifacts. If your just plopping windows out you won't see these artifacts until they start moving around on the screen in a consistent rate you will actually find the window have a gitter effect. Thats basically what I mean by out-of-vsync artifacts.

Theres no additional memcpy, you have two buffers in video memory. One which is the displaying buffer (primary buffer), the other is the offscreen or also called the back buffer. And lets suppose you have a few buffers that needs to be rendered (that doesn't stay at the same spot of the screen), those all get copied to the back buffer accordingly, then a switch occurs with the primary and back buffer effectively making the back buffer the primary (displaying buffer), and your recent primary buffer is now the back buffer, and then drawing to the new effective back buffer. I'm not exactly sure how in hardware level this happends but I think its just exchanging the memory address pointer of the displaying buffer in video memory. Hope this makes any sense.

Edit: I just thought of a better example to explain this, take the VCR for example if you hold on fast forward your pictures seem to be slightly diagonal, this is because the some parts of the new fram is shown while the last frame is still on display. This is the same case when your directly drawing into primary buffer rather then prerendering them onto a back buffer and flipping them.

Double buffering is used for GUI, it stops people seeing the screen being updated.
But can make mouse cursor look floaty, on slower PC.
The other big addvantage is that you can have all you graphic functions write to the buffer in a set bpp, then only the write buffer to screen function needs to be changed for 24bits or 32bit .

wow i completely forgot about the page thingy in hardware; I have been copying the buffer to video memory every vsync interval thingy

Double bufferging: render into one buffer, then wait for vsync, then while the monitor is doing the vsync wither swap the rendered buffer with the previous buffer (hardware double buffering) or copy your rendered buffer to screen buffer (software double buffering). That's all there is.

Just a little side question,
Do the regular port registers 0x3c** and 0x3d** for the video card that allow use to check Vsynch work when we are using VESA modes?

I mean, once i change the video mode into a Vesa mode,Is the register field stating that a Vsynch has started/ended still valid?

And if they are not valid, how do you check for Vsynch in VESA modes?

On VGA compatible cards the vsync and hsync bits are found in register 3DAh. The VESA BIOS should give you information on VGA compatibility of the specific mode when you query, a certain bit in the ModeInfoBlock (page 15 of vbe3.pdf).