From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KmZaA-0004ab-85 for mharc-grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:58 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KmZa9-0004ZM-06 for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KmZa8-0004YK-7K for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:56 -0400 Received: from [199.232.76.173] (port=58305 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KmZa7-0004YC-Pq for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:55 -0400 Received: from gateway01.websitewelcome.com ([69.41.242.19]:34126) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KmZa7-0000Cm-6t for grub-devel@gnu.org; Sun, 05 Oct 2008 15:47:55 -0400 Received: (qmail 22151 invoked from network); 5 Oct 2008 20:05:16 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway01.websitewelcome.com with SMTP; 5 Oct 2008 20:05:16 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:52374 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KmZa1-0001FP-7a for grub-devel@gnu.org; Sun, 05 Oct 2008 14:47:49 -0500 Date: Sun, 5 Oct 2008 12:47:23 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081005124723.56912905@gibibit.com> In-Reply-To: <1454803125.39941223234262084.JavaMail.root@aczmb1> References: <1745824252.39921223234235570.JavaMail.root@aczmb1> <1454803125.39941223234262084.JavaMail.root@aczmb1> 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_/sVsrw+k=nZorAg+u1vdIrFl"; 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 19:47:57 -0000 --Sig_/sVsrw+k=nZorAg+u1vdIrFl Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Sun, 5 Oct 2008 14:17:42 -0500 (CDT) Andy Goth wrote: > "Colin D Bennett" wrote: > > However, in double buffered mode the last rendered frame might=20 > > not be in the back buffer after calling swap_buffers, depending=20 > > on the double buffering strategy selected at runtime: > >=20 > > 1. page flipping is in use > > 2. back buffer is in main memory >=20 > With a little bookkeeping you can avoid having to redraw the whole > screen. Here are some strategies: >=20 > (double buffering with page flipping and drawing to main memory) >=20 > Draw to a buffer in main memory. Maintain a list of changed > regions. This is your list of dirty rectangles. After completing a > frame, blit the dirty rectangles to the page that's about to get > flipped into view. Age all dirty rectangles by one frame, and remove > all dirty rectangles that were previously aged. If the dirty > rectangle list gets too long, just blit the whole screen. Clever > algorithms can combine dirty rectangles to save memory. >=20 > (double buffering with page flipping without drawing to main memory) >=20 > Draw to the back buffer, and maintain a dirty rectangle list. > Immediately after vertical retrace start, flip pages, and blit the > dirty rectangles to the new back buffer from the (now being > displayed) old back buffer. Empty the dirty rectangle list. >=20 > (double buffering without page flipping) >=20 > Draw to a buffer in main memory, and maintain a dirty rectangle > list. During vertical retrace, blit the dirty rectangles to VRAM. > Empty the dirty rectangle list. >=20 > (single buffering with minimal shearing) >=20 > Draw to VRAM. Wait for the start of vertical retrace before > drawing. Hopefully all drawing can complete before the monitor gets > repainted. >=20 > (single buffering) >=20 > Draw to VRAM. >=20 > Disclaimer: I don't actually know what you're trying to do (plain > text, drop shadows, animation, 3D graphics... no clue), so the stuff > I suggest might be overkill. Nevertheless, I hope it is helpful. Thanks for the ideas. Also, I know it is possible to write code that is optimal for each case, my plan is to avoid complicated dirty-region repaint strategies at first. ("First make it work, then make it rock.") After everything is working, then we can profile and do performance optimization. After everything is functioning and performance bottlenecks are identified, then we can perhaps use some techniques like you suggest. Thanks, Colin --Sig_/sVsrw+k=nZorAg+u1vdIrFl Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjpGdAACgkQokx8fzcGbYdmvACgldYKypvL4yTOY1yfoe+mPJwX bc0An3QWMtQ9wtRwq3KMZ+1c1kUnm4lm =Pxac -----END PGP SIGNATURE----- --Sig_/sVsrw+k=nZorAg+u1vdIrFl--