From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmvM2-0003hk-5c for mharc-grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:50 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmvM0-0003gK-H3 for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmvLz-0003g8-TQ for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:48 -0400 Received: from [199.232.76.173] (port=47479 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmvLz-0003g5-QC for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:47 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:55386 helo=jenni2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KmvLz-00047U-3j for grub-devel@gnu.org; Mon, 06 Oct 2008 15:02:47 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni2.inet.fi (8.5.014) id 48DA2F0A00A82D57 for grub-devel@gnu.org; Mon, 6 Oct 2008 22:02:46 +0300 Message-ID: <48EA60D6.7060708@nic.fi> Date: Mon, 06 Oct 2008 22:02:46 +0300 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 References: <777113540.40311223236640078.JavaMail.root@aczmb1> In-Reply-To: <777113540.40311223236640078.JavaMail.root@aczmb1> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: Quoted-Printable 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, 06 Oct 2008 19:02:48 -0000 Andy Goth wrote: > "Colin D Bennett" wrote: >> First make it work, then make it rock. >=20 > I certainly do appreciate that, but... >=20 >> my plan is to avoid complicated dirty-region repaint strategies=20 >> at first. >=20 > Requiring full-screen repaints is an architectural design that might ne= ed rework to undo later. Or might not, depending on how you implement it= . The interim approach you choose now should be informed by foresight. >=20 > Full-screen repaint approach that will require rework later: >=20 > - One function draws everything in sequence. It gets called every fram= e. >=20 > Full-screen repaint approach that will be easy to integrate into a part= ial update scheme: >=20 > - A separate function exists for drawing each logical unit of the scree= n. > - Every frame, one function calls all the separate functions in sequenc= e. >=20 > Or something like that. Hi, 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. 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 properl= y. 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. Thanks, Vesa J=C3=A4=C3=A4skel=C3=A4inen