From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpQbY-0000mB-Fo for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:12 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpQbX-0000m3-6I for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:11 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpQbV-0000kA-8Y for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:10 -0400 Received: from [199.232.76.173] (port=36454 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpQbV-0000k0-58 for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:09 -0400 Received: from gateway11.websitewelcome.com ([67.18.7.10]:48597) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpQbU-0003nP-Ko for grub-devel@gnu.org; Mon, 13 Oct 2008 12:49:08 -0400 Received: (qmail 18862 invoked from network); 13 Oct 2008 17:01:17 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway11.websitewelcome.com with SMTP; 13 Oct 2008 17:01:17 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:57183 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpQbP-0005R1-4n for grub-devel@gnu.org; Mon, 13 Oct 2008 11:49:03 -0500 Date: Mon, 13 Oct 2008 09:48:15 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081013094815.733491bb@gibibit.com> In-Reply-To: <48EA60D6.7060708@nic.fi> References: <777113540.40311223236640078.JavaMail.root@aczmb1> <48EA60D6.7060708@nic.fi> X-Mailer: Claws Mail 3.5.0 (GTK+ 2.14.3; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: multipart/signed; boundary="Sig_/0/BHle6TCstu1SBxHOlbheJ"; 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: Mon, 13 Oct 2008 16:49:11 -0000 --Sig_/0/BHle6TCstu1SBxHOlbheJ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 06 Oct 2008 22:02:46 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Andy Goth wrote: > > "Colin D Bennett" wrote: > > Requiring full-screen repaints is an architectural design that > > might need rework to undo later. Or might not, depending on how > > you implement it. The interim approach you choose now should be > > informed by foresight. > [...] > Hi, >=20 > I would like to thank Andy for his comments on the topic. I do share > the same concern about designing double buffering to work properly > without making hasty implementation first. We can use non-buffered > solution as a first stage "hasty implementation" and design good > enough solution to handle double buffering well. >=20 > Dirty rectangles for every buffer (two in double buffer case) might be > the best approach here. I think there is some kind of dirty rectangle > implementation on gfxterm so that could be used as a base for this > work. After that it could be improved to increase performance but the > main point being that there has to be proper framework to make it > work properly. >=20 > Usually the slowest step is to transfer image data from main memory to > video memory (and usually the slowest is to read from video memory to > main memory and then save it back to video memory). If we can optimize > memory copies between video and main memories we are on good track to > solve speed problem. I agree that a dirty region repaint management system will provide better performance, but I certainly do not have time to implement it now. IMO that would take a lot of work. I *am* interested in getting high performance, but (1) I simply don't have time to do it myself right now, and=20 (2) gfxmenu seems plenty fast to me--I have run Lua-driven full screen animations as a desktop background for gfxmenu, and it worked fantastically. The menu system performs decently even on my ultra-low-power-but-low-performance-too Via C3 system. Granted, the gfxterm terminal is nearly unusable right now, but I think its performance can be improved significantly through a few relatively minor changes. Regards, Colin --Sig_/0/BHle6TCstu1SBxHOlbheJ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjze9IACgkQokx8fzcGbYdfHACfRarZxw0k1As/sqoDcYa9SFbd xeIAn3jWOijnLrEzEaCbcZCyGyRMbtbd =q0RM -----END PGP SIGNATURE----- --Sig_/0/BHle6TCstu1SBxHOlbheJ--