Drawing on windowed screen buffers

[tinman]

I'm not sure if I'm missing something, but shouldn't the two buffers have different things on them? Run this program and drag other windows over this one to force a repaint. Instead of two different images of squares in different positions I get one long rectangle.

You'll also notice if you take the top flipbuffers() and add another to the repaint event handler that you will also see the rectangles. How is this possible if I draw on the back buffer and call flipbuffers() twice (so that the original back buffer is again the back buffer).

Code: Select all

If InitSprite()=0 : End : EndIf

Procedure draw(x)
    StartDrawing(ScreenOutput())
    Box(x, 10, 10, 10, RGB(255,0,0))
    StopDrawing()
EndProcedure

If OpenWindow(0, -1, -1, 400, 300, #PB_Window_SystemMenu|#PB_Window_MinimizeGadget|#PB_Window_MaximizeGadget|#PB_Window_SizeGadget|#PB_Window_TitleBar, "blah!")
    If OpenWindowedScreen(WindowID(), 140, 20, 200, 200, 0, 20, 20)
        SetFrameRate(2)
        draw(10)
        FlipBuffers()
        draw(20)
    
        Repeat
            ev.l = WaitWindowEvent()
            While ev
                Select ev
                    Case #PB_Event_CloseWindow
                        quit = 1
                        
                    Case #PB_Event_Repaint
                        Debug "Repaint"
                        FlipBuffers()
                EndSelect
                
                ev = WindowEvent()
            Wend
        Until quit=1
    EndIf
EndIf
End

Thanks.

[dmoc]

Tinman, I'll try your code later but from what you describe (anyone else feel free to correct me) flipbuffers/repaint *blits* the back buffer to the front buffer and doesn't simply swap ptrs to gfx memory (as flipbuffers() might lead you to believe).

[DarkDragon]

And I found no ClearScreen in your code, so you are making a motion blur.

[tinman]

And I found no ClearScreen in your code, so you are making a motion blur.

Why should I need to clear the screen? There are two buffers and both should be independant images. When I display one then it is the only one that gets displayed. They should not get combined.

At least this is what double buffering has always meant to me.

[dmoc]

AFAIK double buffering has always worked by providing a hidden buffer which is transferred to the front buffer once you have finished drawing.

[tinman]

AFAIK double buffering has always worked by providing a hidden buffer which is transferred to the front buffer once you have finished drawing.

This isn't how it is described in the FlipBuffers() command (although, yes, I know the PB documentation isn't the most reliable).

If you think about it flipping the buffers, rather than copying the back buffer to the front buffer, is the only way you can guarantee flicker free displays. You only change the address where the display is drawn from rather than having to copy the entire contents of the display.

Fred, any thoughts on this issue?

[DarkDragon]

And I found no ClearScreen in your code, so you are making a motion blur.

Why should I need to clear the screen? There are two buffers and both should be independant images. When I display one then it is the only one that gets displayed. They should not get combined.

At least this is what double buffering has always meant to me.

Und if you don't clear the backbuffer with ClearScreen() the Buffer will have the combined version.

[Pupil]

I agree with tinman, this doesn't look like double buffering. Maybe it's an DX issue when dealing with windowed screens?

[tinman]

Und if you don't clear the backbuffer with ClearScreen() the Buffer will have the combined version.

Why when you should only be swapping display pointers? There's no combination of display going one, it should get drawn separately from a different buffer.

There shouldn't need to be a clear screen. Check out some similar code in a screen:

Code: Select all

If InitSprite()=0 : End : EndIf
If InitKeyboard()=0 : End : EndIf

If OpenScreen(1280, 1024, 32, "")
    Repeat
        ExamineKeyboard()
        If KeyboardPushed(#PB_Key_Escape)
            quit = 1
        Else
            db = 1 - db
            StartDrawing(ScreenOutput())
            Box(50+db*10, 50, 10, 10, RGB(255, 0, 0))
            StopDrawing()
            FlipBuffers()
            Delay(500)
        EndIf
    Until quit=1

    CloseScreen()
EndIf
End

[dmoc]

...is the only way you can guarantee flicker free displays. You only change the address where the display is drawn from rather than having to copy the entire contents of the display.

...unless the blit is vsynch'ed. Think about this: if you were building up a complex picture, draw something, dislpay it, draw some more, display it, etc, until you had the full picture, you would still have to blit the intermediate results to the (now) off-screen buffer. I'm not arguing one method/scheme over another but from your original post the only explanation is what I describe. An example of where the "ptr" swap is definately used (from my experience) is stereoscopic display where the left/right buffers are entirely seperate but even in this case I would not be surprised if a single backbuffer is used and blitted to the l/r buffer as required.

[tinman]

but from your original post the only explanation is what I describe.

Yeah, fair enough - it does describe whats happening.

But to me that's just a pain in the ass :), especially when you try similar code in a screen and it works as if there are two separate buffers. However, I can see there being advantages to either method.

I dunno, perhaps its the way Windows does screen overlays or my graphics card drivers are broken.

[DarkDragon]

Uhm thats the same with OpenGL: If you don't clear the screen/window, you'll get a motion blur.