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

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

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

On Sun, 05 Oct 2008 11:52:08 +0300
Vesa J____skel__inen <chaac@nic.fi> wrote:

> Colin D Bennett wrote:
> > Clean patch against trunk SVN revision 1885.
> > 
> > Regards,
> > Colin
> 
> Thanks for the re-base.
> 
> In your opinion how should rendering of double buffered screen be
> different from single buffered?
> 
> Eg. who is responsible to handle those differences?
> 
> Thanks,
> Vesa J__skel_inen

Generally, the client code should (IMO) do the following, which will
work for both a double-buffered and a non-double-buffered video mode:
(by 'client', I mean the code that is using the video API)

  // Render the graphical elements to the back buffer.
  grub_video_fill_rect (...);
  grub_video_draw_string (...);
  grub_video_blit_bitmap (...);
  // Make the back buffer contents visible.
  grub_video_swap_buffers ();    // NOP in single buffered mode

For double buffered mode, this properly renders the graphics using
double buffering.  For non double buffered mode, the "back buffer" and
the "front buffer" are one and the same, and the 'swap_buffers'
operation does nothing.

I think the main difference between rendering to a single buffered
versus a double buffered screen is the fact that when rendering using
single buffering, the client code can update only the changed parts of
the screen, but for double buffering it must update the whole screen.

In single buffered mode, you can incrementally modify the video memory
contents based on the last rendered frame.  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. when page flipping is in use, the back buffer will contain the
   contents of the screen before the *prior* call to swap_buffers.

2. when the back buffer is in main memory (the blit strategy), the back
   buffer will actually retain its contents after swap_buffers, since
   the buffers cannot actually be swapped (thus perhaps the
   'swap_buffers' name is not the most accurate description of the
   essence of this function, but it gets the general message across).

In the gfxmenu code, I decided that, at least to start with, to always
render complete frames on the screen.  In this way, the code functions
properly whether or not double buffering is in use, and it is kept
simple.  This worked well for the menu screen, and has good performance
in my tests even on my 1 GHz VIA C3 machine.  I figure that it's more
important to get it working properly, and then optimize the
performance later where it might be needed.

The main current performance problem lies in the way that the gfxterm
works when embedded in the double buffered gfxmenu screen. It is causing
a full screen redraw every time a character or a string is changed on
the terminal. I've thought about this a lot in the past and I don't
have a simple answer, though I have a lot of ideas (switch to single
buffering temporarily (--), pre-render a bitmap of the rest of
the screen (-), coalesce updates to the gfxterm (++), ...).

Regards,
Colin

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