2023.9.1-PR116: Move sbitmap to EHMTX::queue

[andrewjswan]

#116 (comment)

[andrewjswan]

Didn't notice the increase in size...
Before:

RAM:   [=         ]  14.4% (used 47152 bytes from 327680 bytes)
Flash: [========= ]  86.2% (used 1582105 bytes from 1835008 bytes)

After

RAM:   [=         ]  14.4% (used 47152 bytes from 327680 bytes)
Flash: [========= ]  86.2% (used 1581913 bytes from 1835008 bytes)

[andrewjswan]

4 days, no problems, everything is stable in all modes.

[lubeda]

This is a waste of RAM if you are using other components like a microphone or other components, this isn't good. I agree with having more dynamic icons would be nice, but not like this. Perhaps you can set the amount of sbitmaps at compile time and introduce a new screen_type bitmapx_screen => {"bitmap_slot","[0,4523,0,2342,0,..... (64 values 16bit values rgb565)]", "lifetime", "screen_time"}, this is an acceptable compromise (I think).

[andrewjswan]

I haven't noticed any problems, I have WEB enabled, and other additional sensors, no memory issues.

[andrewjswan]

To save memory, it is necessary to make a dynamic queue and a dynamic array of icons, then when adding an entity will be created and added to the required list, when it is not needed memory is released.
But it is better to do it in Version 3. Here this variant works perfectly well.

[andrewjswan]

@lubeda We can try to make this array dynamic:

Color* sbitmap;

and allocate memory as needed:

if (sbitmap== NULL) 
{
  sbitmap= new Color[64];
}

But I don’t yet know where to properly clean it. When a screen is removed from the queue.

[andrewjswan]

I changed sbitmap to a dynamic array, checked it, it works.

[andrewjswan]

About three to five screens a day. Everything's stable. No degradation has been noticed.

[andrewjswan]

Conflict resolved.

[lubeda]

nice implementation

[andrewjswan]

Thanks