Re: [PATCH] GSoC #07 VBE double buffering (vs r1885)

[Colin D Bennett <colin@gibibit.com>]

[-- Attachment #1: Type: text/plain, Size: 2555 bytes --]

On Sun, 5 Oct 2008 14:17:42 -0500 (CDT)
Andy Goth <unununium@aircanopy.net> wrote:

> "Colin D Bennett" <colin@gibibit.com> wrote:
> > However, in double buffered mode the last rendered frame might 
> > not be in the back buffer after calling swap_buffers, depending 
> > on the double buffering strategy selected at runtime:
> > 
> > 1. page flipping is in use
> > 2. back buffer is in main memory
> 
> With a little bookkeeping you can avoid having to redraw the whole
> screen.  Here are some strategies:
> 
> (double buffering with page flipping and drawing to main memory)
> 
> Draw to a buffer in main memory.  Maintain a list of changed
> regions.  This is your list of dirty rectangles.  After completing a
> frame, blit the dirty rectangles to the page that's about to get
> flipped into view.  Age all dirty rectangles by one frame, and remove
> all dirty rectangles that were previously aged.  If the dirty
> rectangle list gets too long, just blit the whole screen.  Clever
> algorithms can combine dirty rectangles to save memory.
> 
> (double buffering with page flipping without drawing to main memory)
> 
> Draw to the back buffer, and maintain a dirty rectangle list.
> Immediately after vertical retrace start, flip pages, and blit the
> dirty rectangles to the new back buffer from the (now being
> displayed) old back buffer.  Empty the dirty rectangle list.
> 
> (double buffering without page flipping)
> 
> Draw to a buffer in main memory, and maintain a dirty rectangle
> list.  During vertical retrace, blit the dirty rectangles to VRAM.
> Empty the dirty rectangle list.
> 
> (single buffering with minimal shearing)
> 
> Draw to VRAM.  Wait for the start of vertical retrace before
> drawing.  Hopefully all drawing can complete before the monitor gets
> repainted.
> 
> (single buffering)
> 
> Draw to VRAM.
> 
> Disclaimer: I don't actually know what you're trying to do (plain
> text, drop shadows, animation, 3D graphics... no clue), so the stuff
> I suggest might be overkill.  Nevertheless, I hope it is helpful.

Thanks for the ideas.  Also, I know it is possible to write code that
is optimal for each case, my plan is to avoid complicated dirty-region
repaint strategies at first.  ("First make it work, then make it
rock.")  After everything is working, then we can profile and do
performance optimization.  After everything is functioning and
performance bottlenecks are identified, then we can perhaps use some
techniques like you suggest.

Thanks,
Colin

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]