From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1EgByT-0006XL-1O for mharc-grub-devel@gnu.org; Sat, 26 Nov 2005 21:09:05 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EgByR-0006Wo-F0 for grub-devel@gnu.org; Sat, 26 Nov 2005 21:09:03 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EgByP-0006W7-PD for grub-devel@gnu.org; Sat, 26 Nov 2005 21:09:03 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EgByP-0006W2-LG for grub-devel@gnu.org; Sat, 26 Nov 2005 21:09:01 -0500 Received: from [157.24.2.30] (helo=smtp1.cc.lut.fi) by monty-python.gnu.org with esmtp (Exim 4.34) id 1EgByP-0006xm-F0 for grub-devel@gnu.org; Sat, 26 Nov 2005 21:09:01 -0500 Received: from localhost (smtp1 [127.0.0.1]) by smtp1.cc.lut.fi (Postfix) with ESMTP id B65E77014A for ; Sun, 27 Nov 2005 04:09:00 +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 08523-07 for ; Sun, 27 Nov 2005 04:09:00 +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 69D867012B for ; Sun, 27 Nov 2005 04:08:59 +0200 (EET) Message-ID: <43891540.6010103@nic.fi> Date: Sun, 27 Nov 2005 04:09:04 +0200 From: =?UTF-8?B?VmVzYSBKw6TDpHNrZWzDpGluZW4=?= User-Agent: Thunderbird 1.4.1 (Windows/20051006) MIME-Version: 1.0 To: The development of GRUB 2 References: <435B72E9.6070603@nic.fi> <200511252125.29459.okuji@enbug.org> <4387AC45.20208@nic.fi> <200511262052.53100.okuji@enbug.org> In-Reply-To: <200511262052.53100.okuji@enbug.org> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=UTF-8 X-Virus-Scanned: by lut.fi Content-Transfer-Encoding: quoted-printable Subject: Re: Video subsystem draft 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: Sun, 27 Nov 2005 02:09:03 -0000 Yoshinori K. Okuji wrote: > On Saturday 26 November 2005 01:28 am, Vesa J=C3=A4=C3=A4skel=C3=A4inen= wrote: >>> Compression might make the performance horrible, because PPF is very >>> optimized. >> When there is a caching implemented in a one day, it's only initial >> cost. So far I haven't seen performance problems with this. But then >> again I haven't tried it too much. >=20 > I must test it myself, too. The performance of reading a compressed fil= e is=20 > slow, because of seeking. Seeking forward is fast, but seeking backward= is=20 > very slow. So compression makes sense for OS images, but not much for f= ont=20 > files. > The most important part is the initial cost, BTW. Since a boot loader m= ust be=20 > quick to start up (otherwise, the user loses some seconds every time),=20 > caching is not so important. There is this transparent gzip support in gz file open, that diagnoses file to decide wether it is gzipped or not. If there is transparent option specified, it can also read nongzipped files. This would allow user to pack font file if there is a need to compress it (of course with cost of speed) If I remember correctly I also saw caching of sectors in disk code, so basicly if disk cache is big enough old font data will already be in memory. And this will only cause little delay as there is no I/O latency. Actual testing in real hardware will tell how good this is. I am currently only running this on vmware.