Animartrix usermod improvements and speedups

[softhack007]

This tickets is a summary of ongoing improvements for Animartrix effects.

Currently achieved speedup: 20-40% depending on effect used.

Generic fixes

• bugfix: some effects call the 1D version of setPixelColor(), leading to unwanted behaviour in case that the last 1D segment expand mode was not "pixels". --> enforce using 2D
• bugfix: changing segment size, or changing "mirror" or "transpose" must lead to effect re-init
• feature: add checkbox for optional gamma correction

• move gamma correction to usermod level settings, instead of a per-effect option

Effect framerate

All Animartrix effects are calculated in pure float. This means there is no possibility for speedups, unless core animartrix functions would be re-written for fixed point (integer) math. But some tweaks could help

• overwrite math functions like sinf() cosf() etc with speed-optimized approximations (wled_math.h)
• raise compiler optimization temporarily: -ffast-math (= ditch IEEE compliance, allows for unfair/inaccurate math optimizations)
• tell the compiler to treat all "literals" as float (normally a single value without ".0f" means that the compiler has to use double) -fsingle-precision-constant

RAM usage

Large lookup tables in RAM: effects use two huge lookup tables (2D vectors) that need 4*width*height bytes each. For 64x64 pixels this is 32KB extra RAM, fragmented into blocks of 256 bytes.

• Try to force tables into PSRAM (needs a custom allocator for the vector template)
  --> can only be done in Animartix core - separate PR for original repo Add custom PSRAM allocator for ESP32 lookup tables softhack007/animartrix-esp32#2

[netmindz]

Gamma correction - it was originally built against FastLED, but then later work was done against SmartMatrix hub75, then my OO port was based off the SmartMatrix branch of AnimARTrix, then for WLED we have swapped from SmartMatrix to the driver from mrcodetastic, I must admit I've got rather lost with regards to which layer is best to be applying gamma correction in and if that differs between WLED-MM based off 14 and WLED 16

I don't know if there is a good software architecture/philosophy that we should try to apply as to where in the stack gamma correction should be handed, e.g do you say apply only in the driver and if it driver does not support, then the Bus implementation need to apply before we pass to the driver?

[softhack007]

don't know if there is a good software architecture/philosophy that we should try to apply as to where in the stack gamma correction should be handed, e.g do you say apply only in the driver and if it driver does not support, then the Bus implementation need to apply before we pass to the driver?

In our version (MM based on upstream 0.14.) its complicated - basically neither bus nor driver level apply any gamma correction, and the effect has to provide gamma-corrected colours already. Actually the HUB75 driver even needs to revert gamma correction if we use the driver's own CIE color correction (currently MM does not use this feature).

In upstream 0.16 the concept is better - the bus driver will do gamma correction, and everything "above" (segment and strip) handle uncorrected colours. Better concept :-) but it meant that all builtin palettes
needed to be "gamma-clean" and lots of hunting for duplicate gamma correction in legacy code.

Tl;dr: in MM, the effect has to take care of gamma correction, that's why I added it in the anim.setpixelColor() method. For upstream compatibility, the gamma correction should be fully inside #ifdef _MoonModules_WLED_.

Edit: for compatibility, your proposal to make "apply gamma" a usermod option is better, instead of having the feature per effect.

[ewowi]

In WLED-MM, Shouldn't you delete all gamma correction in effects and everything not part of the drivers (bus)? Sounds like the way to go ?