Opened 11 years ago

Closed 10 years ago

#2843 closed bug (fixed)

Mesa software renderer doesn't support double buffering

Reported by: korli Owned by: korli
Priority: normal Milestone: R1
Component: Kits/OpenGL Kit Version: R1/pre-alpha1
Keywords: Cc: mysticmike@…
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

I don't know how to check this feature though.

Change History (4)

comment:1 by phoudoin, 11 years ago

He does double buffering in OpenGL lingua, aka primitives currently emitted are not immediatly visible, but only at buffers swap they (all) will.

What it does NOT is GUI double buffering.

If a region of the BGLView is invalidated:

  • when BDirectWindow mode is enabled, nothing is redrawn until next SwapBuffers(), leaving us with a view's background colored hole (black, but used to be transparent, even worse!). As the next swap is not necessarely around the corner, in particular when the OpenGL scene is not animated, this bug can be well visible.
  • otherwise, the current content of the offscreen bitmap is used to refresh the region.

Unfortunatly, in both case the offscreen bitmap content is not the frame currently displayed but, if any primitive have been emitted already since last swap - glClear() being the most obvious one, the work-in-progress/next frame... Hence visible artefacts.

For full double buffering, we'll needs two offscreen BBitmaps, one being the read-only visible frame, the second being the read-write (drawing) frame. Which leads to a triple buffers design: # drawing buffer, where all directives are drawn # display buffer, which is the last buffer being paint to screen and used to repaint as needed # screen frame buffer, eventually containing part (clipping) converted (color-spaces) copy of the display buffer.

Buffers 1 and 2 are the ones that should be swapped now.

One performance advantage here is that blitting the display buffer can be done asynchronously while the next frame is prepared, which we can't do currently with an unique offscreen bitmap...

in reply to:  1 comment:2 by phoudoin, 11 years ago

Sorry, I screw wiki formatting of this part:

For full double buffering, we'll needs two offscreen BBitmaps, one being the read-only visible frame, the second being the read-write (drawing) frame. Which leads to a triple buffers design:

  1. drawing buffer, where all directives are drawn
  2. display buffer, previous drawing buffer, painted to screen and used to repaint as needed
  3. screen frame buffer, eventually containing part (clipping) converted (color-spaces) copy of the display buffer.

comment:3 by mysticmike, 11 years ago

Cc: mysticmike@… added

comment:4 by korli, 10 years ago

Resolution: fixed
Status: newclosed

Hopefully ok in hrev33234.

Note: See TracTickets for help on using tickets.