From: Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] [RFC] Splash image
Date: Wed, 18 Jul 2007 10:31:25 -0400 [thread overview]
Message-ID: <469E243D.3060309@smiths-aerospace.com> (raw)
In-Reply-To: <20070718135815.GF4836@enneenne.com>
Rodolfo Giometti wrote:
> On Wed, Jul 18, 2007 at 09:40:28AM -0400, Joey Oravec wrote:
>> "Rodolfo Giometti" <giometti@enneenne.com> wrote in message
>> news:20070718083012.GE4836 at enneenne.com...
>>> I'm planning to review the splash image support and in order to do that
>>> my next steps should be:
>>>
>>> 1) Remove the logo support.
>> As long as it's modular, I agreed because the two functions are nearly
>> identical. It's important to add/remove code to keep the size down. Probably
>> should test for a pointer to a compressed (gzip) image, uncompress, then
>> call the bmp_display.
>
> I think we should remove it definitely... it's just doubled code.
>
>>> 2) Rewrite the lcd_display_bitmap() in order to be more portable
>>> across several BPP values.
>> Keep it modular; have a bitmap_display(addr, x, y) robust to bpp that is
>> called from an lcd_display_splash_screen(). Account for 24-bit LCDs and
>> files. The bit-per-pixel data structure was a poor-fit with 24-bit, and I
>> didn't even try to support colormapped files on a truecolor display. Great
>> idea because it might save a ton of flash to display an 8bpp image on a
>> 24bpp display.
>>
>> 3. If there's an overall flash savings, it would be nice to support GIF,
>> PNG, or some other format smaller than a BMP. How complex is the parsing,
>> and would it be a net savings on flash?
>
> I think we should support just one format for two reasons:
>
> 1) Supporting just one format keep the code smallest.
>
> 2) We have "convert". :)
>
>> 4. Account for text overlay on splash screen. There are callbacks for bootup
>> progress, and it's nice to lcd_printf() the status to some rectangle on the
>> screen. Even better if it scrolls or clears nicely.
>>
>> 5. Document and improve the videolfb ATAG. I hardcode my framebuffer to the
>> end of RAM, don't tell linux to use that memory, and pass the info to linux.
>> The display still flickers until you remove the re-initialization, but at
>> least Linux won't move and therefore clobber the contents of the
>> framebuffer.
>
> I dislike this feature. :) IMHO I think it introduces several problems
> and complications whose can be avoided just defining a boot logo into
> Linux... however it could be keep into some consideration.
>
> Thanks for your suggestions,
>
> Rodolfo
FWIIW, I took a screenshot, saved it as a 16 bit BMP, then converted the
BMP as a GIF, JPEG, and a PNG. While very unscientific, this says BMP
with gzip is a winner for two reasons:
1) It is similar in compression ratios to PNG and GIF
2) We already know how to gunzip and BMP.
Benchmark:
495410 screenshot-16.bmp
25411 screenshot-16.bmp.gz
25875 screenshot-16.PNG
37727 screenshot-16.GIF
148854 screenshot-16.JPG
(Trivia: I did JPEG because it was there. It is generally a poor choice
for splash screens because it has artifacts on sharp transitions, which
splash screens tend to have.)
gvb
next prev parent reply other threads:[~2007-07-18 14:31 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-07-18 8:30 [U-Boot-Users] [RFC] Splash image Rodolfo Giometti
2007-07-18 13:40 ` Joey Oravec
2007-07-18 13:58 ` Rodolfo Giometti
2007-07-18 14:31 ` Jerry Van Baren [this message]
2007-07-18 15:32 ` Rodolfo Giometti
2007-07-18 14:47 ` Wolfgang Grandegger
2007-07-18 15:37 ` Rodolfo Giometti
2007-07-18 16:03 ` Wolfgang Grandegger
2007-07-18 16:01 ` Rodolfo Giometti
2007-07-18 16:17 ` Wolfgang Grandegger
2007-07-19 8:36 ` Rodolfo Giometti
2007-07-19 9:47 ` Wolfgang Grandegger
2007-07-19 9:52 ` Rodolfo Giometti
2007-07-19 14:18 ` Rodolfo Giometti
2007-07-19 14:41 ` Wolfgang Grandegger
2007-07-19 14:40 ` Rodolfo Giometti
2007-07-19 7:09 ` Matthias Fuchs
2007-07-19 8:19 ` Wolfgang Grandegger
2007-07-19 8:33 ` Rodolfo Giometti
[not found] <008901c7ca10$f1921a40$d4b64ec0$@com>
2007-07-19 20:30 ` Wolfgang Grandegger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=469E243D.3060309@smiths-aerospace.com \
--to=gerald.vanbaren@smiths-aerospace.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.