Marlin: Feature: Animated Custom Bootscreen

[N95JPL]

Hello,
I have made an adapted version of the 2.x.x branch which includes support for a 5-Frame Animated Custom Bootscreen.

Would such a feature be allowed to merge with the branch to make it availiable for all?

Thanks,
Joshua

[Roxy-3D]

Yes. It probably should be flexible about the number of frames... (with a definable option)
Post a Pull Request of it and that should start the discussion about what else needs to be done to get it into compliance with Marlin's coding standards.

[AnHardt]

The central questions are:

• What is it good for?
• What will it cost?
• Can it be switched off, so it does not use any additional resources?

[Roxy-3D]

Can it be switched off, so it does not use any additional resources?

Absolutely!!!! Without this ability, it is a non-starter.

[N95JPL]

The central questions are:
What is it good for?

• Some people like it!

What will it cost?

• I will look into the extra memory it uses when I return home tomorrow.

Can it be switched off, so it does not use any additional resources?

• Completely, new option in .configuration under "//#define SHOW_CUSTOM_BOOTSCREEN" - So it can show a single custom screen OR the animation.

As for number of frames, I am working on this - I had one way but it didn't work very well.

It so far only works for DOGM (Tevo Tornado user here) - and extends _bootscreen.h with the additional frames.
I have an idea for a more compacted coding but wanted to see if it would be worth-while pursuing it!

[Roxy-3D]

The extra frames will just end up being stored in PGM memory... If there is extra space there, there is no harm to having the extra frames. In that case the space is unused and just sitting empty.

But to handle the case where Program Memory is almost full... it might be good to let the user select how many frames of the sequence to show. And then use #if statements to cut out the later frames of the sequence if the user specified less than what is defined for the sequence.

That would let the user fall back to a single frame if memory is tight. Or maybe just a few frames if they can't afford the full sequence.

[N95JPL]

Yes agreed - there is still the single frame option.
I made:

define CUSTOM_BOOTSCREEN_ANIMATION - so you can disable that and just have;

define SHOW_CUSTOM_BOOTSCREEN - Activated for 1 frame

I will work on it more tomorrow before I submit it to the Pull Request!
I will edit the new option to be followed by a number (Number of frames) EG:

define CUSTOM_BOOTSCREEN_ANIMATION 5 // Number of frames to be shown in animation

That can kill 2 birds then;
The #if ENABLED(CUSTOM_BOOTSCREEN_ANIMATION)
and #if CUSTOM_BOOTSCREEN_ANIMATION == 5

[thinkyhead]

If you wanted to be clever about it and save PROGMEM, you could use "delta animation" which would provide the first bitmap plus the differences between the frames (produced by a pre-processing script). The code to play the animation would be a bit more complex, but it would take up far less PROGMEM than even a single bitmap.

[N95JPL]

Thanks for the input, that's something I will look into! The lighter I can get it the better!
Thanks again

[ejtagle]

Not only that, you can save even more space and increase speed at the same time by using RLE compression of franes and delta frames.
On my experiments, and using vertical stripes of 8 pixels, I easily get 1/8 of the original size for typical images.
I use an special encoding for RLE, to improve compression and take into account the typical values seen on monochrome images:

RLE command byte: bits 76543210

76= 00 RLE 0x00 value, 543210=count of times-1
76= 10 RLE 0xff value, 543210=count of times-1
76=01 RLE value in next byte, 543210=count of times-1
76=00 No RLE. Next 543210=count of following bytes -1 to copy

The above scheme works extremely well for monochrome images and vertical stripping of images of 8 pixels wide.

RLE decompression is even faster than reading raw data from progmem.

I have used this scheme, not only for images, but also for font data for several years. I have written the associated compressor in C++ (not production quality code, but it works!) and my idea was to donate it to Marlin at some point, but i eventually desisted, because it should be integrated to u8glib, and that is something that won´t happen...

[marcio-ao]

@ejtagle: The biggest issue I see with RLE encoding is that in order for it not to use SRAM, you would need to unpack while writing bytes to the display via SPI. Not sure whether u8g lib in it's current incarnation can do that. Right now the only option may be to unpack the bitmap to SRAM, and then call u8g lib to send it over. Not ideal.

[marcio-ao]

@ejtagle: I did something similar when trying to play video on a RepRap Discount display

[ejtagle]

@marcio-ao : If using u8glib, you do exactly the same (but will end decompressing 2-4 times each frame, as u8glib does horizontal strips.
You will end with mostly the same speed than using raw bitmaps, but 1/8 of the size.

Yes, i agree it is not ideal. To integrate the code into u8glib is the best approach

[ejtagle]

@ejtagle: The biggest issue I see with RLE encoding is that in order for it not to use SRAM, you would need to unpack while writing bytes to the display via SPI. Not sure whether u8g lib in it's current incarnation can do that. Right now the only option may be to unpack the bitmap to SRAM, and then call u8g lib to send it over. Not ideal.

You can unpack while using setPixel using u8glib. The problem is using SRAM globals. Using stack space is not a problem

[thinkyhead]

For RLE it would be best to set bytes, not pixels. I haven't explored u8glib lately, but I assume it has a method to set individual bytes (or horizontal runs of them) without taking up too much SPI bandwidth? And it should only do unpacking for the current u8g.page. Seems like an interesting experiment, if nothing else.

[ejtagle]

@thinkyhead : Unfortunately not. u8glib has a(n) SRAM buffer that contains the current u8g.page. And it composes everything in that page before sending it, so, there is no way to escaping sending a whole "page" through SPI..
That is something that makes u8glib not so light (for our requirements)

[Uskompuf]

So did this get implemented?

[shitcreek]

There is BOOT_MARLIN_LOGO_ANIMATED in the config advance file.

[Uskompuf]

Is there any documentation, I couldn't find any here: http://marlinfw.org/docs/configuration/configuration.html#firmware-info

[shitcreek]

I think it was added only four months ago and we've been adding and changing a lot of stuff and so the documentation is bit behind. We will be updating the documentation site to better reflect all the features of 2.0.

[Uskompuf]

Did documentation ever get written?

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.