[PATCH] Bootsplash enhancement

[stpere]

I have centered (vertically) the icons in the bootsplash and put the logo to sit right on top of them.. In other words, I have moved the whole boot splash up. You can see the result in the attached screenshot. I have also included the patch (of course).

[stpere]

Screenshot of the modification

[stpere]

The patch file

[stpere]

The patch that allows positionning in images.h

[stpere]

I have enhanced my patch, allowing to position the bootsplash logo using percentages put in boot/images.h.. (as it was asked in a TODO clause - by stippi, if I'm not mistaken) Use the file bootsplash.diff (the more recent)

[meanwhile]

I think that the total of 'Haiku logo + icons' looks best with a vertically centered Haiku logo, in other words: like the way it is right now. However, if you want to emphasize the icons by vertically centering them, a solution might be to do so while replacing the haiku logo to the same bottom-right position where it used to be for a long time (the white underlining might then become too much). This is highly subjective, so all of the 'FWIW' and 'just my 2 cents' etc. need to be applied here ;)

[stippi]

Replying to meanwhile:

I think that the total of 'Haiku logo + icons' looks best with a vertically centered Haiku logo, in other words: like the way it is right now. However, if you want to emphasize the icons by vertically centering them, a solution might be to do so while replacing the haiku logo to the same bottom-right position where it used to be for a long time (the white underlining might then become too much). This is highly subjective, so all of the 'FWIW' and 'just my 2 cents' etc. need to be applied here ;)

Yes, I came to the same conclusion after messing with different possibilities in WonderBrush.

Ok, there is still stuff that could be done, shall I keep the ticket open? The code could be made to generate and handle indexed colors, and also it could use compression/decompression (simple RLE). I won't work on any of that for now, so feel free to play!

[stippi]

Actually, I do feel like working on the RLE compression.

[stpere]

I will leave you the RLE, I will focus on another enhancement / aestetic change I have in mind (on another part of Haiku).. (however, if you change your mind, I could do it too)

[stippi]

Yeah, turns out I need to do something else first. So please go ahead with the RLE implementation, after that, I could change the code to support two alternative images for different screen sizes. If I did that without the compression, Axel would come over and hurt me for the resulting kernel size...

[axeld]

The best thing would be if the image data would be in some resource (either external file or actual kernel resources) that can be thrown away after use.

That way, the image size and number wouldn't matter at all, since all memory could be reused after having shown the boot screen.

[stpere]

Should I implement RLE first, then re-factor the bootsplash to use a resource? Or directly implement the later idea (resource..) without doing any compression ? Because if we use a resource and are able to drop it after the bootsplash, I don't see much usefulness in compressing/decompressing the image (not that it is THAT expensive).

[axeld]

Whatever you prefer to work on, I guess :-) About the usefulness of a compression or not, I would say that entirely depends on the size and number of the images we're talking about. Smaller size usually reduces loading times, too.

[stpere]

With RLE compression - removed duplications of image data..

[stpere]

haiku/headers/private/kernel/boot/images.h file

[stpere]

Okay, here are the changes I've done :

1. generate_boot_splash compress the image using simple RLE when writing it to images.h (I have included a reference images.h) The resulting file is a lot smaller (365K rather than near 1MB) There is probably room for more improvement because a lot of {1, 0xNN} appears in the middle of the array.

2. The image data was included both in the bootloader and the kernel. Now it's included in the bootloader, decompressed in the bootloader and passed to the kernel using kernelArgs.

3. I clear the uncompressed logo image after it's been blitted.. however I can't seem to do the same with the uncompressed icons.

So, these changes results in a smaller kernel and smaller bootloader. Here are some stats about those savings :

before after saving module 1289 1217 72 ./x86/release/system/kernel/kernel.so 1125 1053 72 ./x86/release/system/kernel/kernel_x86 372 324 48 ./x86/release/system/boot/boot_loader_bios_ia32 320 272 48 ./x86/release/system/boot/zbeos

NOTE: these numbers are in kbytes.

[stippi]

Thanks a lot for your patch, I applied it in hrev24812.

[stpere]

haiku/headers/private/kernel/boot/images.h file (version 4)

[stpere]

Enhanced RLE, see comment

[stpere]

New version of the RLE encoding/decoding (based on suggestions from stippi)!

What's new :

1. smaller bootloader (again) because I don't use uint16 for counts.. that limits myself to a count of 127 (see 2. for why 127), but I'm winning in the long run because I don't lose a byte each time I have a count of, say.. 3, 4 or any other small count..

2. If some data cannot be compressed by RLE, because they aren't in a run (like 0x00 0x00 0x00...) but rather like (0x06 0x03 0xf5...), I put a negative count (count + 128, in fact) and simply write the said data without putting the count for that section.

So if 0x06 0x03 0xf5 would have been encoded as : 1, 0x06, 1, 0x03, 1, 0xf5,

this is now encoded as : -3, 0x06, 0x03, 0xf5

In this simple case, we just saved 2 bytes. But we are reserving/losing all counts of over 128 for this trick.

3. I encode the color channels separately because we often got something like this to encode before :

0x00 0x30 0xfe 0x00 0x30 0xfe 0x00 0x30 0xfe that meant it was a single color repeating itself, but my first implementation couldn't compress it.

4. I have made the necessary adjustments to decoder in order to support this new format. I have optimized it a bit to help reduce the loading time. I know BeOS has a good reputation in regards with its boottime :)

Numbers :

/x86/release/system/boot/boot_loader_bios_ia32 before RLE: 372 KB after RLE (first implementation): 324KB after RLE (latest): 296KB

/x86/release/system/boot/zbeos before RLE: 320 after RLE (first): 272 after RLE (latest): 248

/x86/release/system/kernel/kernel_x86 before RLE: 1125 after RLE (first): 1053 after RLE (latest): 1057 (this is with a later revision which added some kernel code, I didn't change anything to the kernel for this implementation)

[stippi]

Oh btw, I consider this one done. The only thing left to do is actually adding this in the build system, but no reason to keep the bug open. Thanks a lot, Philippe!