Palette effect will not spread palette colors across entire strip

[blazoncek]

What happened?

If the strip (or segment) pixel count is larger than 256 pixels, the effect will spread colors only across 256 pixels and then repeat, instead of spreading colors across entire strip (or segment) length.

To Reproduce Bug

Create a strip (or segment) with more than 256 pixels (preferably more than 384 to pronounce the effect) and select Palette effect.
You will see a sharp color transition at pixel 256.

Expected Behavior

Spread palette colors across entire strip (or segment) even if pixel count is larger than 256 pixels.

Install Method

Self-Compiled

What version of WLED?

WLED 0.15.0

Which microcontroller/board are you seeing the problem on?

ESP8266

Relevant log/trace output

No response

Anything else?

The bug was introduced with #3683 when using SEGMENT.color_wheel() which only takes 256 values instead of SEGEMENT.color_from_palette().
cc @TripleWhy

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

That's odd. I cannot reproduce after restarting the unit.

EDIT: Visible on ESP8266 but not on ESP32

[DedeHai]

does changing the FX to use floats also on the ESP8266 fix it? with the new integer based sin/cos functions it should not make any noticeable difference in speed, it may increase flash usage a bit.

[TripleWhy]

I don't currently have access to any esp devices for testing, but I can look into it within the next two weeks if no one else does it first. I looked at just the code a bit, but nothing immediately catches my eye.

About the float usage: We could try that for testing purposes, but I would be very surprised if the 8266 behaved any different from the esp32 then. However, I would expect it to be much slower with the float version: Most of the float computations I eliminated with the switch are in the actual function. The trigonometry calls are actually just 2 per function execution, so the new trig functions shouldn't have a huge impact here.

(Btw. I wasn't aware there are esp32 variants without an FPU when I wrote the effect. A switch depending on the existence of an FPU could make more sense than one that tests for esp2866.)

What I would be interested in, only for earlier poking without hardware, would be:

• Does the anamorphic option have any effect on this?
• Do any other effect parameters have any influence? If so, it could be helpful if you post a repro preset.
• Does this work on 0d279cb?

I'm not up to date with the current state of the project. Which branch should I check out for investigating this?

[blazoncek]

Anamorphic fixes it.

Otherwise, just click effect and unselect rotation animation but leave shift animation selected.
You can work on main branch now.

[blazoncek]

FYI reducing sInt16Scale from 0x7FFF to 0x3FFF fixes the issue for lengths of 450 or less (tested).
I do not know what else this change does but it definitely has an effect.

[TripleWhy]

Fix in #4435, I believe. As mentioned, I am currently unable to test this on actual hardware.

[DedeHai]

I just tried to reproduce this, and fix or no fix, it looks the same on my setup.
I do: ESP8266, Palette FX, rainbow palette, 400 LEDs, size set to 133 and I do see a smooth transition over the whole strip. Using the code from the PR looks identical. I am afraid I cannot reproduce this. Any additional info?

[blazoncek]

Leave size at 128 and try 450 pixels.

Anyway, the proposed fix resolves issues for my set-up.

[DedeHai]

Ok, got it now, can confirm the PR fixes it.