Surfacing screen memory allocation

[Ellerbach]

Description

Surfacing screen memory allocation

Motivation and Context

• When doing intensive graphic like UI with gif, jpg and other elements, the needed graphic memory can be higher than the default allocated one
• Surfacing for all M5Stack which has a screen the capacity to allocate manually this memory
• The mechanism uses a default value and is compatible with all the current implementations

How Has This Been Tested?

Real devices

Screenshots

Types of changes

• Improvement (non-breaking change that improves a feature, code or algorithm)
• Bug fix (non-breaking change which fixes an issue with code or algorithm)
• New feature (non-breaking change which adds functionality to code)
• Breaking change (fix or feature that would cause existing functionality to change)
• Config and build (change in the configuration and build system, has no impact on code or features)
• Dependencies (update dependencies and changes associated, has no impact on code or features)
• Unit Tests (add new Unit Test(s) or improved existing one(s), has no impact on code or features)
• Documentation (changes or updates in the documentation, has no impact on code or features)

Checklist:

• My code follows the code style of this project (only if there are changes in source code).
• My changes require an update to the documentation (there are changes that require the docs website to be updated).
• I have updated the documentation accordingly (the changes require an update on the docs in this repo).
• I have read the CONTRIBUTING document.
• I have tested everything locally and all new and existing tests passed (only if there are changes in source code).
• I have added new tests to cover my changes.

[Ellerbach]

@josesimoes is it ok to ignore the SonarCloud warnings? It's mainly because of duplicate code.

[josesimoes]

LGTM! Nice improvement, BTW. 👏🏻

[josesimoes]

@Ellerbach sonar analysis has a point on the assignment of the static field MemoryAllocationBitmap... any harm on not having it static?

As for the duplicated, it's OK.

[Ellerbach]

Yes and no. I was thinking of best way to solve it. I need the field to be static and it's assigned only in the constructor of the screen as we can't have it static :-) So by design, this has to be like this.

[josesimoes]

Yes and no. I was thinking of best way to solve it. I need the field to be static and it's assigned only in the constructor of the screen as we can't have it static :-) So by design, this has to be like this.

Understood. Then go for merge!