From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1FHRyp-0001XN-I4 for mharc-grub-devel@gnu.org; Thu, 09 Mar 2006 15:43:27 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FHRyn-0001Pe-Pt for grub-devel@gnu.org; Thu, 09 Mar 2006 15:43:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FHRyi-0001DP-RT for grub-devel@gnu.org; Thu, 09 Mar 2006 15:43:25 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FHRyi-0001CW-Nq for grub-devel@gnu.org; Thu, 09 Mar 2006 15:43:20 -0500 Received: from [157.24.2.30] (helo=smtp1.cc.lut.fi) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FHS1r-00049I-2e for grub-devel@gnu.org; Thu, 09 Mar 2006 15:46:35 -0500 Received: from localhost (smtp1 [127.0.0.1]) by smtp1.cc.lut.fi (Postfix) with ESMTP id 0BCFF70430 for ; Thu, 9 Mar 2006 22:43:17 +0200 (EET) Received: from smtp1.cc.lut.fi ([127.0.0.1]) by localhost (smtp1.cc.lut.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24917-08 for ; Thu, 9 Mar 2006 22:43:16 +0200 (EET) Received: from [192.168.1.100] (lk4-a-4-1.lnet.lut.fi [157.24.102.107]) by smtp1.cc.lut.fi (Postfix) with ESMTP id ABE117033D for ; Thu, 9 Mar 2006 22:43:16 +0200 (EET) Message-ID: <4410936A.4070204@nic.fi> Date: Thu, 09 Mar 2006 22:43:22 +0200 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: The development of GRUB 2 References: <4407474E.6060708@nic.fi> <87y7zrg34j.fsf@xs4all.nl> <44085F78.8020409@nic.fi> <200603052225.23523.okuji@enbug.org> <440C93E2.8050202@nic.fi> In-Reply-To: <440C93E2.8050202@nic.fi> X-Enigmail-Version: 0.93.2.0 Content-Type: text/plain; charset=ISO-8859-1 X-Virus-Scanned: by lut.fi Content-Transfer-Encoding: quoted-printable Subject: Re: New patch for video subsystem... 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: Thu, 09 Mar 2006 20:43:26 -0000 Vesa J=E4=E4skel=E4inen wrote: > Yoshinori K. Okuji wrote: >> On Friday 03 March 2006 15:23, Vesa J=E4=E4skel=E4inen wrote: >>> Nowadays 1024x768 is a normal standard resolution. >> Even if it is very popular, since the boot loader is a critical part o= f an=20 >> operation system, the default should be set to something really safe. = So I=20 >> prefer 640x480. It is up to the user (or the vendor shipping GRUB) to = change=20 >> it to something more comfortable. >=20 > Ok. I will change the default to that. I will only make new patch if > there are issues to be solved before commit. While waiting for more comments or approval I have made some changes, but I will commit them after we have initial set of patches in. 1. Added simple caching to font manager. Implemented as a "pageing", in initial page there is 128 entries to hold glyphs, if it there is need for more glyphs new page will be allocated to and added as a next page. When finding for cached glyph, it first scans root page and then advances to next pages. 2. Added simple buffering to videoterm. If there is enough memory for buffer layer it will allocate it and use it. When rendering, all operations in videoterm goes first to buffer layer, and when all layers has been rendered to it, then it renders buffer to display. If it is not available, we will notice some flickering. I think the next step here would be to either add bitmap loading support (and implement rendering for it) or add more optimal rendering possibilities to VBE driver. Is there a nice way to split vbe driver to more source files without causing generation of more modules. I was thinking that "optimized" versions of some blitting operations would be good to place on some other file as source might grow to quite large. I am open to proposals what to implement next (it could even be something not listed here). Also we need to decide should there be functional changes when user has chosen indexed color modes instead of RGB mode. (Both work now, but indexed color mode more slowly as it tries to find best indexes for RGB values for EVERY drawn pixel :) Thanks, Vesa J=E4=E4skel=E4inen