From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Kq7S8-00078G-0G for mharc-grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:20 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kq7S5-00077o-KQ for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:17 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kq7S3-00077I-Mr for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:17 -0400 Received: from [199.232.76.173] (port=39402 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kq7S3-00077E-EO for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:15 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:52783 helo=kirsi2.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kq7S2-0007jg-SI for grub-devel@gnu.org; Wed, 15 Oct 2008 10:34:15 -0400 Received: from [127.0.0.1] (84.248.105.254) by kirsi2.inet.fi (8.5.014) id 48DA300B01198061 for grub-devel@gnu.org; Wed, 15 Oct 2008 17:34:09 +0300 Message-ID: <48F5FF64.6010500@nic.fi> Date: Wed, 15 Oct 2008 17:34:12 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: The development of GRUB 2 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> <20081014224251.78ee2aa0@gibibit.com> In-Reply-To: <20081014224251.78ee2aa0@gibibit.com> X-Enigmail-Version: 0.95.7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: Quoted-Printable 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 14:34:18 -0000 Colin D Bennett wrote: > On Tue, 14 Oct 2008 00:11:42 +0300 > Vesa J=E4=E4skel=E4inen wrote: > A minor point: You mentioned "RGB" and "RGBA" format--do you mean "tru= e > 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 I stated before order is not an issue. We can use BGR[A]. I am just used to speak about RGB :) >> 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. >=20 > 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) >=20 >=20 > 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; } No, more like: void *lock(bitmap b) { if (b.locked) return NULL; if (b.optimized) return NULL; b.locked =3D 1; return b.dataptr; } void unlock(bitmap b) { b.locked =3D 0; } grub_err_t optimize(bitmap b, rendertarget r) { if (b.locked) return error; if (b.optimized) return error; // do magic b.optimized =3D 1; return success; } Now one would use it like: ptr =3D lock(); if (ptr) { // modify it. ptr[0] =3D blue; ptr[1] =3D green; ptr[2] =3D red; if (has_alpha) ptr[3] =3D alpha; unlock(); } >>> 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). >> 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 :) >=20 > Ok. >=20 > 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. No. If user has low color mode optimize will really make image look ugly. So best to postpone this conversion to far as possible. > 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. I would still like to support all RGB modes. Indexed color modes are just backup option.