From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KpTb9-0004io-50 for mharc-grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:59 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KpTb6-0004hE-4x for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:56 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KpTb5-0004gK-DS for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:55 -0400 Received: from [199.232.76.173] (port=60766 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KpTb5-0004g7-4c for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:55 -0400 Received: from gateway04.websitewelcome.com ([67.18.59.10]:39110) by monty-python.gnu.org with smtp (Exim 4.60) (envelope-from ) id 1KpTb4-0003xV-IZ for grub-devel@gnu.org; Mon, 13 Oct 2008 16:00:54 -0400 Received: (qmail 25475 invoked from network); 13 Oct 2008 20:12:54 -0000 Received: from gator297.hostgator.com (74.53.228.114) by gateway04.websitewelcome.com with SMTP; 13 Oct 2008 20:12:54 -0000 Received: from spk.venturedesignservices.com ([65.61.115.34]:42961 helo=localhost) by gator297.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.68) (envelope-from ) id 1KpTb1-0007vf-Gh for grub-devel@gnu.org; Mon, 13 Oct 2008 15:00:51 -0500 Date: Mon, 13 Oct 2008 13:00:05 -0700 From: Colin D Bennett To: grub-devel@gnu.org Message-ID: <20081013130005.2adac4b2@gibibit.com> In-Reply-To: <48F39322.8060508@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> 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_/DH0Roj_1n2ogOywlUkg2DFj"; 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: Mon, 13 Oct 2008 20:00:56 -0000 --Sig_/DH0Roj_1n2ogOywlUkg2DFj Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, 13 Oct 2008 21:27:46 +0300 Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > Colin D Bennett wrote: > > On Fri, 03 Oct 2008 23:16:51 +0300 > > Vesa J=C3=A4=C3=A4skel=C3=A4inen wrote: > >> I have been thinking this a bit and I think best solution to > >> bitmaps is something like following. > >> > >> Two types of bitmap: easily accessible and optimized bitmaps for > >> hardware. > >> > >> Easily accessible are meant to be modified by user and provides > >> slow blitting performance. Basically we should only support two > >> formats. RGB888 and ARGB8888 (order can be different). This way we > >> can make easy code to modify bitmaps. > >> > >> When there is no need to modify bitmap anymore, one calls > >> grub_video_bitmap_optimize(bitmap, rendering_target) and then > >> bitmap is optimized to match reder_targets format. > >> > >> there would be two new helpers that gives access to bitmap data. > >> grub_video_bitmap_lock() and to release it > >> grub_video_bitmap_unlock(). Lock will fail if bitmap is optimized. > >=20 > > What is the effect of lock/unlock on an unoptimized bitmap? Is it > > like a reference counting memory management scheme? >=20 > 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. 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. 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 am wondering should we have grub_video_bitmap_unoptimize() to map > >> back to editable mode. But that might be more pain and promote bad > >> ways to do conversion. > >=20 > > If some code needed to modify an optimized bitmap, we could just > > have that code keep the unoptimized version of the bitmap around for > > modification, and just re-optimize the bitmap after modifying it. > > Of course it would only make sense to optimize bitmaps that will be > > blitted more than once. >=20 > And if bitmap is animated, there is no good reason to optimize it > either. Agreed -- an animated bitmap is just a specific instance of a single use bitmap. > >> Now bitmap loaders would be modified to return data in easily > >> accessible format so bitmaps can be modified and so on. > >> > >> Now to bitmap scaling. This can only be done for easily accessible > >> formats and could be something like this: > >> > >> +grub_err_t > >> +grub_video_bitmap_create_scaled (struct grub_video_bitmap **dst, > >> + int dst_width, int dst_height, > >> + struct grub_video_bitmap *src, > >> + enum > >> + grub_video_bitmap_scale_method > >> scale_method); > >> > >> Now in example static bitmaps would be optimized right away in > >> order to make their blitting fast. I do not know if we need special > >> handling for transparent bitmaps. May need some experimenting. > >=20 > > I have been scaling bitmaps with alpha transparency and it works > > fine with the scaling code in the patch. It's used for the menu > > frame, the selected item highlight, and entry icons, to name a few > > uses. >=20 > Well... For our use it should be sufficient. So lets use that. Ok. > >> Actual scalers would be hidden from API and can only be specified > >> by enum type. > >=20 > > Ok; sounds good. > >=20 > >> It could be a good idea to implement all scalers in same file. > >> Unless there is some weird scaler that needs thousands of lines of > >> code. > >=20 > > I'm fine with that. (Though in general my preference is for short > > source files: 900+ line files become like a labyrinth of code, a > > maze of twisty passages all alike.) >=20 > True. But sometimes it is good idea to keep it in same place. I didn't > look at the files but I think it should not be too long. In example > you can hide those other methods with static specifier. Yes, it might be best here to simply put it all in one file--sounds fine to me. I agree that making things static is a benefit of putting all related stuff together in a file, to improve encapsulation. Regards, Colin --Sig_/DH0Roj_1n2ogOywlUkg2DFj Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkjzqMYACgkQokx8fzcGbYeZMACfVCIw+zkgNJi1PixmWCZ8oDPR kycAnitTpG4PueWNznH1MBJGdw4g0gV4 =BK9s -----END PGP SIGNATURE----- --Sig_/DH0Roj_1n2ogOywlUkg2DFj--