[haiku-development] Re: [PATCH] Add 8-bit indexed colour support to boot splash

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-development@xxxxxxxxxxxxx
  • Date: Sat, 02 Aug 2008 18:32:23 +0200 CEST

"David Powell" <david@xxxxxxxxxxxxxxxxx> wrote:
> 2008/7/29 Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> > Spacing of the function calls is wrong - it's always fprintf("")
> > not
> > fprintf ("") nor fprintf( "" ) :-)
> > Also, looking at the end of the patch, the output looks wrong, too,
> > as
> > there is an additional tab before the last '};'.
> > Other than that, the patch looks good to me.
> Do you want me to fix those issues and re-submit the patch, or should
> I fix them later?

I would prefer to fix them before committing the patch, at least. Looks
like later anyway ;-)

> > Grayscale is probably enough for the moment. You could do a simple
> > palette replacement algorithm instead of a real color conversion,
> > though -- dunno if that would look better, though.
> > If we just do a simple conversion like this, I would actually
> > prefer to
> > do it "live" in the boot loader, though; at least it should consume
> > less space, and should still be pretty much instant.
> Since posting the patch, I've been working on the
> generate_boot_screen
> program, and I've managed to add "Gervautz-Purgathofer octree
> quantization"
> to the program, which means that it can now generate an optimized 256
> colour
> palette. (It's a open source implementation that I've tweaked, I
> wouldn't want to take credit for stuff that isn't mine)
>
> I've also added a nearest-colour mapping, which gives pretty good
> result
> for an indexed colour image. I'm currently working on applying a
> dither algorithm to the image
> to make it look even better, though I may submit a patch without the
> dither, as
> it's a significant improvement on the greyscale image anyhow.
>
> The upshot of all of that is that the colour image in 8-bit mode
> looks
> really good,
> however the genereate_boot_screen can take a second or two to run
> with the
> colour quantization, and probably longer once I get dithering to
> work,
> so I don't think it would be a good idea to include those algorithms
> in the bootloader to
> do it "live" as there would be a noticable speed penalty.

Okay, but at least it would then only hit those people that actually
use it rather than everyone ;-)
Anyway, that sounds like a worthwhile approach.
Would it be faster if the palette was created by the
generate_boot_screen command, and if the
boot loader would only do the color lookup?

Bye,
   Axel.


Other related posts: