Opened 11 years ago

Closed 11 years ago

#1999 closed enhancement (fixed)

[PATCH] Bootsplash enhancement

Reported by: stpere Owned by: stippi
Priority: normal Milestone: R1
Component: - General Version: R1/pre-alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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).

Attachments (7)

Capture.png (122.1 KB) - added by stpere 11 years ago.
Screenshot of the modification
stpere_bootsplash.diff (1.2 KB) - added by stpere 11 years ago.
The patch file
bootsplash.diff (3.7 KB) - added by stpere 11 years ago.
The patch that allows positionning in images.h
patch_bootsplash_20080405.diff (7.2 KB) - added by stpere 11 years ago.
With RLE compression - removed duplications of image data..
images.h (364.2 KB) - added by stpere 11 years ago.
haiku/headers/private/kernel/boot/images.h file
images.h.gz (107.5 KB) - added by stpere 11 years ago.
haiku/headers/private/kernel/boot/images.h file (version 4)
patch_bootsplash_20080406.diff (7.5 KB) - added by stpere 11 years ago.
Enhanced RLE, see comment

Download all attachments as: .zip

Change History (21)

Changed 11 years ago by stpere

Attachment: Capture.png added

Screenshot of the modification

Changed 11 years ago by stpere

Attachment: stpere_bootsplash.diff added

The patch file

Changed 11 years ago by stpere

Attachment: bootsplash.diff added

The patch that allows positionning in images.h

comment:1 Changed 11 years ago by stpere

Summary: Bootsplash enhancement[PATCH] Bootsplash enhancement

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)

comment:2 Changed 11 years ago by stippi

Owner: changed from axeld to stippi
Status: newassigned

comment:3 Changed 11 years ago by 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 ;)

comment:4 in reply to:  3 Changed 11 years ago by 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!

comment:5 Changed 11 years ago by stippi

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

comment:6 Changed 11 years ago by 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)

comment:7 Changed 11 years ago by 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...

comment:8 Changed 11 years ago by 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.

comment:9 Changed 11 years ago by 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).

comment:10 Changed 11 years ago by 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.

Changed 11 years ago by stpere

With RLE compression - removed duplications of image data..

Changed 11 years ago by stpere

Attachment: images.h added

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

comment:11 Changed 11 years ago by 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.
  1. 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.
  1. 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.

comment:12 Changed 11 years ago by stippi

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

Changed 11 years ago by stpere

Attachment: images.h.gz added

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

Changed 11 years ago by stpere

Enhanced RLE, see comment

comment:13 Changed 11 years ago by 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..
  1. 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.

  1. 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.

  1. 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)

comment:14 Changed 11 years ago by stippi

Resolution: fixed
Status: assignedclosed

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!

Note: See TracTickets for help on using tickets.