Bugs in blending styles

[DedeHai]

What happened?

Playing with blending styles I found these issues:

• when transition time is set >1s, the first transition after selecting a new style does not start from the beginning
• during transitions, FPS limit is disabled, making all PS effects speed up (this may be related to the new FPS limit handling)

To Reproduce Bug

see above

Expected Behavior

• animations always start from beginning
• no chang in FPS limit during transitions

Install Method

Self-Compiled

What version of WLED?

nightly

Which microcontroller/board are you seeing the problem on?

ESP32-C3

Relevant log/trace output

Anything else?

No response

Code of Conduct

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

[DedeHai]

I want to add the "blending" on brightness change to the list. I only tested that on 2D so far and it makes 2D setups unusable with anything other than "fade". I dont think anyone wants to go to base color every time the brightness changes.

edit:
it is the same in 1D. to reproduce: choose any effect other than solid, set to swipe right for example, change brightness.

[DedeHai]

I did some investigation on the "FPS limit not respected" issue. Printing out time intervals between service() shows it is correct. however, there seems something odd about transitions, FPS do drop a lot even if it is not an FX transition, for example I set the transition time to 5s, ran three "soap" FX in overlay (to stress the MCU more) and compared 0.15 to 0.16:

in 0.15 there is barely any change in FPS, in 0.16 it drops significantly. I can confirm this is happening only since the "blending styles" were merged.
@softhack007 do you know what is going on here? may this be related to your update to FPS limit/timing handling? Unfortunately the commits are all over so I was not able to pin it to any commit.

edit:
during my testing, commenting this line made the FPS drop go away (and also breaks transitions, so just as a hint): https://github.com/Aircoookie/WLED/blob/4d53e0adde054519e84b5bc1b637452980ff9975/wled00/FX_fcn.cpp#L1531

[blazoncek]

What if you move min() out of function call?

unsigned frameDelay2 = (*_mode[seg.currentMode()])();
if (frameDelay2 < frameDelay) frameDelay = frameDelay2;

[DedeHai]

The issue is actually not the frame delay, that stays constant and correct.
what may be at play is how old/new FX is treated during non-FX transitions. So far I was not able to decipher what exactly is going on but FPS drop suggests that effects are executed twice now where as in the old code it was not.

[blazoncek]

effects are executed twice now where as in the old code it was not.

That is correct and expected if you want to transition from one effect to another. Unfortunately if effect does not change it is still run twice as color/palette change may need rewriting LED data.

[DedeHai]

can it be skipped in fade mode?
The double-execution of course makes sense in other transition styles but in fade it just slows down the FX "for no apparent reason", also some effects can speed up (all PS effects for example, maybe some others as well).
Since fade was the default up to now, it should behave the same as before.

[blazoncek]

Not with current implementation. It would require additional checking.

[blazoncek]

FYI if you did not notice in previous versions, there was an abrupt change of effect at some point of transition.

[blazoncek]

I've taken a look on how to improve performance and visual appeal of blending styles (perhaps a better word would be transitions styles). Here's what to look out for if you'll be doing any experimentation:

• effects use SEGCOLOR(x) extensively
• effects use SEGPALETTE extensively
• effects have no knowledge if they are "old" (previous) or "new" (next) effect
• effects have no knowledge if they are in transition or not
• effect function always paints entire canvas (isPixelClipped() will return from pixel drawing function prematurely if pixel is clipped, but effect will still draw on entire segment)
• color_from_palette() can only distinguish if it is using temporary/transitioning palette for particular pixel if using mapping
• transitions do not distinguish if they transition color, palette or effect or any combination of these

If we want to transition each separately, we would need to somehow made:

• SEGCOLOR(x) aware for which pixel it is intended for (clipped or non-clipped)
• SEGPALETTE switch between "new" palette or "old" palette depending on if pixel (currently drawn) is clipped or not
• run effect function twice if we are transitioning from one effect to another (very important for push style transitions) but not otherwise

Current implementation (which always runs effect function twice) deals well with every aspect unless transition style is push and effect is the same. The only downside is loss of performance.
If the effect is the same and more or less static it may still look OK-ish. If it is dynamic it will look awful as it will look as it is being drawn twice.

[blazoncek]

@DedeHai unified-blend branch in my fork has effect transition styles (AKA blending styles but I will use transition style from now on) reworked and to me they seem much improved. I removed double call to effect function if transition style is FADE and the effect itself does not change but for other conditions two calls to effect functions are still there.

FPS is also improved. ESP8266 is able to run at 50 FPS when transition occurs on a 16x16 matrix.

[DedeHai]

I will check it out hopefully later this week.