Allow 2D panel to be larger than 256px in both dimensions

[lexszero]

Increase MAX_LEDS_PER_BUS and change width and height type in WS2812FX class to uint16_t from uint8_t, which overflowed when attempted to configure a panel larger than 255 pixels.

[blazoncek]

The use of uint8_t is intentional.

[lexszero]

The use of uint8_t is intentional.

Interesting, what's the purpose and what this change will break?
And how I should go about setting up 300x10 matrix? What I saw is width overflowed uint8_t resulting in my matrix being 44x10 - this change makes it work correctly.

[blazoncek]

If you want this to be included, modify to be ESP32 only.
Verify other parts of the code not to break anything (UI, JSON API, etc). You'll need to check and discover yourself.

[softhack007]

@lexszero please clarify how you tested your proposed modification.

Did you check that all 2D effects work as before? What about effects like drip or popcorn, which have a special "column mode" when bar is selected as mapping?

I would expect that some 2D effects - like octopus or crazy bee - will not work when rows or cols is greater than 255.

[softhack007]

@lexszero important: please rebase your PR to our 0_15 branch.

[softhack007]

After a quick look, there is a lot more work to be done if you really want to use panels with more than 256 pixels in one dimension. For example

• segment and panel data that still use uint8_t (like segment startY, stopY, and panel (2D setup) width and height)
• lots of support functions still have uint8_t parameter or locals - so all occurrences of int8_t and uint8_t must be scrutinised in fx.h, fx_fcn.cpp, fx_2Dfcn.cpp.
• effects that use uint8_t for local vars must be scrutinised.
• the use of fastled 8bit math (abs8, map8, sin8, etc.) must be checked, and effects to be adjusted to support 16bit XY coordinates (width and height).
• UI features (js, html, json, XML, ws) must be checked to be sure they are able to support 16bit ranges instead of 8bit.
• support on 8266 to be clarified (RAM usage)

In total, I think this PR is just the beginning of a longer journey... and the core team definitely cannot do it without volunteers helping us.

[softhack007]

closing - PR had no activity since almost 2 years, and the proposed solution is only a partial solution - panel dimensions > 255 pixels will still not work as expected with the changes proposed in this PR.