Skip to content

Rainbowsparkle fix #23

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
May 21, 2020
Merged

Rainbowsparkle fix #23

merged 5 commits into from
May 21, 2020

Conversation

rhooper
Copy link

@rhooper rhooper commented May 19, 2020

Refactors the cycle done protocol, refactors SparklePulse to re-use Sparkle and the pulse generator. Fixes dotstar compatibility in a number of spots. Fix RainbowSparkle leaving dots behind. Adds after_draw() to the protocol. Moves primary show() calls to .animate(). Adds Dotstar PWM support to pulse.

Copy link
Contributor

@kattni kattni left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the fixes!

@kattni kattni merged commit 773c5b7 into adafruit:master May 21, 2020
adafruit-adabot added a commit to adafruit/Adafruit_CircuitPython_Bundle that referenced this pull request May 26, 2020
Updating https://github.com/adafruit/Adafruit_CircuitPython_LED_Animation to 2.1.0 from 2.0.1:
  > Merge pull request adafruit/Adafruit_CircuitPython_LED_Animation#26 from kattni/more-example-updates
  > Merge pull request adafruit/Adafruit_CircuitPython_LED_Animation#25 from kattni/example-updates
  > Merge pull request adafruit/Adafruit_CircuitPython_LED_Animation#23 from rhooper/rainbowsparkle-fix
Neradoc added a commit to Neradoc/Adafruit_CircuitPython_LED_Animation that referenced this pull request Jul 18, 2022
The Sparkle animation uses `after_draw` to setup the pixels currently being sparkled for the next frame, assuming `show()` will not be called until then. It also calls `show()` itself first to show the changes made in `draw()`.

The problem is that `animate()` already calls `show()` after calling draw and after_draw. So the frame where the sparkle should show is actually skipped and only briefly appears instead of staying for a frame according to the speed parameter. The refactor from PR adafruit#23 changed the protocol where animations should no longer call `show()` themselves.

We can't change `after_draw` to be called after the call to show() in animate(), because it will break on animation groups using the same strip. If another animation triggers a show() sooner, it will show the next frame of the sparkle prematurely. It also makes the protocol less predictable.
I have used `animate(False)`, followed by setting a pixel an calling `show()` for example to force the color of a single or a few pixels without going through the hassle of creating pixelmaps or groups (and also to simply make it look like it's superimposed over the animation).

So the solution would be to drop `after_draw` and instead memorize the previous list of pixels and set them back in the next draw.
Neradoc added a commit to Neradoc/Adafruit_CircuitPython_LED_Animation that referenced this pull request Jul 18, 2022
The Sparkle animation uses `after_draw` to setup the pixels currently being sparkled for the next frame, assuming `show()` will not be called until then. It also calls `show()` itself first to show the changes made in `draw()`.

The problem is that `animate()` already calls `show()` after calling draw and after_draw. So the frame where the sparkle should show is actually skipped and only briefly appears instead of staying for a frame according to the speed parameter. The refactor from PR adafruit#23 changed the protocol where animations should no longer call `show()` themselves.

We can't change `after_draw` to be called after the call to show() in animate(), because it will break on animation groups using the same strip. If another animation triggers a show() sooner, it will show the next frame of the sparkle prematurely. It also makes the protocol less predictable.
I have used `animate(False)`, followed by setting a pixel an calling `show()` for example to force the color of a single or a few pixels without going through the hassle of creating pixelmaps or groups (and also to simply make it look like it's superimposed over the animation).

So the solution would be to drop `after_draw` and instead memorize the previous list of pixels and set them back in the next draw.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants