On Sun, 05 Oct 2008 11:52:08 +0300 Vesa J____skel__inen <[EMAIL PROTECTED]> 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
signature.asc
Description: PGP signature
_______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
