Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 05 Feb 2008 16:33:42 +0100
From:      =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no>
To:        Oliver Fromme <olli@lurza.secnetix.de>
Cc:        freebsd-chat@FreeBSD.ORG
Subject:   Re: why is it called /boot/beastie.4th ?
Message-ID:  <86myqfwh7t.fsf@ds4.des.no>
In-Reply-To: <86zlufwi4o.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Tue\, 05 Feb 2008 16\:13\:59 %2B0100")
References:  <200802051332.m15DW2WU020689@lurza.secnetix.de> <86zlufwi4o.fsf@ds4.des.no>

next in thread | previous in thread | raw e-mail | index | archive | help
Dag-Erling Sm=C3=B8rgrav <des@des.no> writes:
> The kernel splash code supports both BMP (courtesy of Mike Smith, IIRC)
> and PCX (courtesy of yours truly).

I've written a number of PCX decoders over the years, BTW, and I
remember that I once wrote a codec for a stripped-down version which
supported only single-plane 8-bit color.  It turns out that for that
specific case, which was the most common at the time, you could achieve
considerably better compression by dropping the padding at the end of
each scan line, and allowing runs to cross from the end of one scan line
to the beginning of the next (with due consideration given to not
exceeding the width of the run length counter).

Of course, RLE pales in comparison with most other lossless algorithms,
even contemporary ones such as the LZ family.  Considering that an LZ
codec can be implemented with a fairly small amount of code and requires
a fairly small amount of memory for the dictionary, and how poorly RLE
performs with anything more complex than line drawings, it is surprising
that ZSoft even considered it, much less used it in their finished
product.

DES
--=20
Dag-Erling Sm=C3=B8rgrav - des@des.no



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?86myqfwh7t.fsf>