From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpzAj-0008BD-CQ for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:49 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpzAh-00089L-5u for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:47 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpzAg-00088A-2E for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:46 -0400 Received: from [199.232.76.173] (port=49005 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpzAf-00087z-RG for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:45 -0400 Received: from gateway03.websitewelcome.com ([69.93.37.21]:54775) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpzAf-0007X2-SU for grub-devel@gnu.org; Wed, 15 Oct 2008 01:43:46 -0400 Received: (qmail 4396 invoked from network); 15 Oct 2008 05:58:36 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway03.websitewelcome.com with SMTP; 15 Oct 2008 05:58:36 -0000 Received: from c-67-185-142-228.hsd1.wa.comcast.net ([67.185.142.228]:39573 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpzAa-0001KS-6K for grub-devel@gnu.org; Wed, 15 Oct 2008 00:43:40 -0500 Date: Tue, 14 Oct 2008 22:42:51 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081014224251.78ee2aa0@gibibit.com> In-Reply-To: <48F3B98E.4060109@nic.fi> References: <20080831000157.0c548199@gamma.lan> <48BAC517.4060002@nic.fi> <48BD5F00.9090902@nic.fi> <48E67DB3.8030408@nic.fi> <20081013100010.22d1dc54@gibibit.com> <48F39322.8060508@nic.fi> <20081013130005.2adac4b2@gibibit.com> <48F3B98E.4060109@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_/2J8IndUJZ2BPQU.RryFkaOz"; 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 #09 Bitmap scaling 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: Wed, 15 Oct 2008 05:43:47 -0000 --Sig_/2J8IndUJZ2BPQU.RryFkaOz Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, 14 Oct 2008 00:11:42 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > On Mon, 13 Oct 2008 21:27:46 +0300 > > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > >> Idea is that if bitmap is still locked you cannot optimize it or > >> you cannot lock it again. And if bitmap is optimized you cannot get > >> pointer to modify it. Eg. Function call returns memory pointer. > >=20 > > I thought perhaps the 'optimize' operation would simply return a > > _new_ (and completely independent from that point forward) bitmap > > equivalent to the input bitmap but in the same format as the > > current video mode uses. >=20 > Problem with that is that it makes supporting code harder to use. With > only handful of supported formats it much easier to write support code > to modify bitmap. If you allow to use any format supported by video > subsystem it is nightmare to support them all. >=20 > So if we just support two formats. We only need to care about RGB and > RGBA formats, rather easy task. Can be modified by using simple loops > or indexing. When we know that there is no modifications to be done > for bitmap, we can just call optimize() and it will convert (edited) > bitmap to fast to blit format. A minor point: You mentioned "RGB" and "RGBA" format--do you mean "true color" (either RGB[A] or BGR[A] layout) or do you mean literal RGB byte order? If we are talking about picking a single component order to standardize on, it should be BGR[A]. Every video adapter I have tested on so far (nVidia 7600GT, VIA Unichrome, VMware, QEMU) has supported BGRA (32 bpp) or BGR (24 bpp) but not RGBA or RGB. Perhaps others have found the contrary to be true; if so I would like to know. > As we have same handle all the time for bitmap we can just continue to > use it as is. If we would make new instance of it, would either need > to delete previous one and replace its usage with new one. Of course > use case here affects. Ok. That's fine. I'm still a little confused about the purpose of lock/unlock, however. Is it basically a way of catching mistakes in the code where we accidentally try to modify bitmap data when we don't want to? I guess what I'm asking is, do lock/unlock do anything more than set a flag that is checked, as in: (pseudocode) void *get_ptr(bitmap b) { if (b.optimized) return error(); return b.ptr;=20 } void optimize(bitmap b) { if (b.locked) error(); /* optimize b... */ } void lock(bitmap b) { if (b.locked) error(); b.locked =3D 1;=20 } void unlock(bitmap b) { b.locked =3D 0; } > > Are you thinking that it would be best to have the > > 'optimize'/'unoptimize' operations actually just modify the bitmap > > in place? I guess this is nice from a memory conservation > > standpoint, but in some cases it wouldn't work well (i.e., 24-bit > > to 32-bit formats). >=20 > I do not think at this point how optimize() or unoptimize() will be > implemented. Just general idea. Whether it is in-place operation or > re-allocation for memory, is same to me. It just have to work :) Ok. Another idea: What if the image-loading functions automatically optimize()'d the bitmaps when loaded, since we don't normally expect to modify loaded bitmaps before display. Then most all the bitmaps in use would automatically get the performance benefit with no change to all the users of the code. The only thing we do with loaded images is the scale them and blit them. The scaling algorithms can easily work on any 24 or 32 bit color mode without knowing details of which components are which (the process is the same regardless of the color component). Thus optimized images could still be scaled highly efficiently (without an unoptimize->scale->optimize process). For 15/16 bit or indexed color modes, we would have to unopt->scale->opt, but I really think that no one should be using those modes. If your video memory is too limited for 24 or 32 bit color, then just use the perfectly great text mode menu. Regards, Colin --Sig_/2J8IndUJZ2BPQU.RryFkaOz Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkj1gt0ACgkQokx8fzcGbYezVQCdGu0K3ahRgGVfNcjb/0o/tsZV PNcAnimE+U64/OimbpQN/oDKFWML3zqT =dLr6 -----END PGP SIGNATURE----- --Sig_/2J8IndUJZ2BPQU.RryFkaOz--