From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpUhj-0002Is-Cd for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:51 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpUhd-0002HD-Va for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:46 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpUhc-0002Gc-N0 for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:45 -0400 Received: from [199.232.76.173] (port=50451 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpUhc-0002GX-D6 for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:44 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:34786 helo=jenni1.inet.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KpUhb-0006EO-Nc for grub-devel@gnu.org; Mon, 13 Oct 2008 17:11:44 -0400 Received: from [127.0.0.1] (84.248.105.254) by jenni1.inet.fi (8.5.014) id 48DA2BD701032468 for grub-devel@gnu.org; Tue, 14 Oct 2008 00:11:42 +0300 Message-ID: <48F3B98E.4060109@nic.fi> Date: Tue, 14 Oct 2008 00:11:42 +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> In-Reply-To: <20081013130005.2adac4b2@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: Mon, 13 Oct 2008 21:11:46 -0000 Colin D Bennett wrote: > On Mon, 13 Oct 2008 21:27:46 +0300 > Vesa J=E4=E4skel=E4inen 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. 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. 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. 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. > 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 :) Thanks, Vesa J=E4=E4skel=E4inen