[RFC] Transition styles #3633
[RFC] Transition styles #3633
Conversation
Show 2D Configuration button by default
Fix wrong power supply info
Add LDR sensor dusk/dawn preset control Usermod
By adding a random string to the path of the js file every time, we make sure to never hit the browser cache.
By setting the response header "Cache-Control" to "no-store" and setting "Expires" to 0, we make sure the browsers and place calling this never store it in cache.
This reverts commit 51dfa9a.
Fix settings caching on some browsers
Fix repeatable action for ir json
* purge old (not yet processes) NTP responses * validate server responses before updating WLED time * purge receive buffer when package is rejected (avoids mem leak on esp32)
when NTP got enabled via UI, WLED would wait up to 12 hours before issuing the first NTP request.
NTP validation, and rejecting malformed responses (related to Aircoookie#3515)
… to allow for effects that modify pixels from the previous frame
|
Alright, I think this is taking shape now. I just added dynamic loading of available transition styles, just like it's done with effects. This way, if effect blending is disabled, we don't show the the drop down in the UI. I'm also filtering out styles that are 2D-only if the strip is 1D. I also added palette transitions now. It's not using the same mechanism as palette blending, since that wouldn't work with some of the transition styles. I think at this point, this covers the full scope of the PR. I'll add a more transition styles in future PRs. So I'll mark this as ready for review. |
| #define TRANSITION_STYLE_OUTSIDE_IN 5 | ||
| #define TRANSITION_STYLE_INSIDE_OUT 6 | ||
| #define TRANSITION_STYLE_FAIRY_DUST 7 | ||
| #define TRANSITION_STYLE_SWIPE_UP 3 |
There was a problem hiding this comment.
I'd group 2D transitions together.
|
Oh, one more thing. |
|
I think it only needs polishing touches. And testing on ESP8266. |
Do I need to open a new PR for that? |
No. You need to merge 0_15 into your branch, resolve possible conflicts and push changes. Then change destination branch of this PR (if you are unable to do that I can do it). |
|
I did the merge as you requested, but I can't set the target branch. Would appreciate if you could do that. |
|
Uh, you should've followed this when creating PR. I'm sorry but didn't notice that before. |
|
I've got a rebased version of my changes. I could either force-push here or open a new PR. |
|
I'd prefer a new PR as this still needs ESP8266 verification and most likely exclusion as having 4+ LED buffers will be to much for it. |
|
Closing in favor of #3669. |
This is work in progress and I am really just looking for feedback suggesting if this is useful and the if the implementation looks ok. Notably, this lacks 2D support, mainly because I have no 2D led matrix (amazon order on the way).
My main goal is to have a transition where the lights in a 1d strip turn on left to right and then stay on. As I looked into how to do this, I noticed that WLED doesn't have native support for transitions other than crossfade. In online forums, the suggestion was to use playlists, but that turned out to be quite tricky to get right. Diving into the source code, I noticed that it's actually not that hard to do "properly": we can support multiple transition styles (this PR implements 5 so far in addition to the default "fade" style, see below), and we can transition every time anything changes, including color, brightness, and effect mode.
The styles implemented so far are:
It's possible to imagine a million more transition styles, and even more so in 2D. However, due to the way this is currently implemented, there are some limitations. For one, the transition is stateless, so it's calculated only using the current transition progress and the old and new pixel color for each pixel. Also due to the fact that transitions are calculated in the setPixelColor() method, we can't do fancy things like e.g. a transition where the old effect is pushed out of the segment to the right and the new one is coming in from the left. That would be doable, but we'd need to calculate the segment with both the old and the new settings and store the color values in separate buffers before applying the transition.
I'd love some feedback. Happy to provide a video that shows the transitional effects if that would help.