2023.9.1: Add screen id support to bitmap_small and add rainbow_bitmap_small

[andrewjswan]

No description provided.

[lubeda]

What's the benefit, you can only have one bitmap_small at a time?

[andrewjswan]

This removes the limitation of one screen with an icon from the HA, you can display more than one

[andrewjswan]

I add rainbow bitmap small screen with screen_id support

[andrewjswan]

What's the benefit, you can only have one bitmap_small at a time?

I didn't notice that the bitmap_small array is not part of the queue object and it can be only one, I need to think how to redesign this nicely without adding an bitmap_small array to each queue element.
Maybe make a separate inheritor?

[andrewjswan]

Although, if we take the maximum, we can have maximum 24 screens const uint8_t MAXQUEUE = 24; in each screen if we add PROGMEM Color sbitmap[64]; we will get 64 * 4 * 24 = 6144 bytes, i.e. 6 kilobytes. Not such a big charge given the availability of flash memory in Esp32.
@lubeda What do you think about it?

[lubeda]

hi, the bitmap array for each queue element was also my plan. This would be the cleaner way to implement instead of providing additional over 20 unused arrays. I need the ram for the voiceassitant and PROGMEM is slower than RAM which is also not optimal.

[andrewjswan]

hi, the bitmap array for each queue element was also my plan.

Do you mean a separate array that is MAXQUEUE in length? Or a separate dynamic array that will be automatically added when a specific screen is added?

I need the ram for the voiceassitant

Ulanzi doesn't have a microphone, or are we talking about a separate device?

PROGMEM is slower than RAM which is also not optimal.

I don't think we'll notice a difference in performance.

[andrewjswan]

@lubeda I’ll make changes for now (I’ll move the array declaration for the icon to the queue), and when you have free time, you’ll do what you planned.