From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmWIW-0003Yg-B1 for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:32 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmWIU-0003Wf-2s for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:30 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmWIT-0003WM-BI for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:29 -0400 Received: from [199.232.76.173] (port=40552 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmWIT-0003WJ-7Y for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:29 -0400 Received: from gateway02.websitewelcome.com ([74.52.222.226]:43298) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KmWIT-0004a2-2I for grub-devel@gnu.org; Sun, 05 Oct 2008 12:17:29 -0400 Received: (qmail 11747 invoked from network); 5 Oct 2008 16:33:42 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway02.websitewelcome.com with SMTP; 5 Oct 2008 16:33:42 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:54969 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KmWIP-00049k-B3 for grub-devel@gnu.org; Sun, 05 Oct 2008 11:17:25 -0500 Date: Sun, 5 Oct 2008 09:16:59 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081005091659.78e70113@gibibit.com> In-Reply-To: <48E88038.6090201@nic.fi> References: <20080830235833.3b29b3c2@gamma.lan> <20081004214328.57e8f709@gibibit.com> <48E88038.6090201@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.12.11; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/Q.El0upi1lh16uOfEZn/Mvs"; protocol="application/pgp-signature"; micalg=PGP-SHA1 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator297.hostgator.com X-AntiAbuse: Original Domain - gnu.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - gibibit.com X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) Subject: Re: [PATCH] GSoC #07 VBE double buffering (vs r1885) X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Oct 2008 16:17:30 -0000 --Sig_/Q.El0upi1lh16uOfEZn/Mvs Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 05 Oct 2008 11:52:08 +0300 Vesa J____skel__inen wrote: > Colin D Bennett wrote: > > Clean patch against trunk SVN revision 1885. > >=20 > > Regards, > > Colin >=20 > Thanks for the re-base. >=20 > In your opinion how should rendering of double buffered screen be > different from single buffered? >=20 > Eg. who is responsible to handle those differences? >=20 > 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 --Sig_/Q.El0upi1lh16uOfEZn/Mvs Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjo6H8ACgkQokx8fzcGbYcVhgCfXXQ+QW4wUdud5FAWTQsZtFy8 9BYAoJNpvhv5zaHk1W/DMmjdjmpOb6yO =VkUY -----END PGP SIGNATURE----- --Sig_/Q.El0upi1lh16uOfEZn/Mvs--