Found a bug in the chase animation when reverse is set to True which results in the animation being offset by the length of the size parameter. You can observe this by setting up two animations of equal length on a single strip of pixels with the second one reversed. The bars should appear to meet in the middle but don't.
Example:
pixels = neopixel.NeoPixel(board.A0, 22, auto_write=False, brightness = .5)
left_pixels = PixelSubset(pixels, 0, 11)
right_pixels = PixelSubset(pixels, 11, 22)
left_animation = Chase(
left_pixels, speed=.5, color=CYAN, size=2, spacing=11
)
right_animation = Chase(
right_pixels, speed=.5, color=CYAN, size=2, spacing=11, reverse=True
)
animations = AnimationSequence(
AnimationGroup(
left_animation,
right_animation,
sync=True
),
auto_clear=True,
auto_reset=True,
)
while True:
animations.animate()
In RainbowComet, the call to `super().__init__()` was missing the
`background_color` argument. This caused strange effects when
non-default arguments were passed.
For example, setting `reverse=True` resulted a red comet with a
tail length of 1, and setting `bounce=True` resulted in a reversed
rainbow comet.
Signed-off-by: Taylor Yu <code@argon.blue>
In a test this improved speed substantially, nearly doubling
the speed of the following test program
```python
pixels = neopixel.NeoPixel(pixel_pin, pixel_num, brightness=1, auto_write=False, pixel_order="RGB")
evens = helper.PixelMap(pixels, [(i,) for i in range(0, pixel_num, 2)], individual_pixels=True)
animation = RainbowChase(evens, 0, spacing=8)
t0 = adafruit_ticks.ticks_ms()
while True:
for i in range(10):
animation.animate(show=False)
t1 = adafruit_ticks.ticks_ms()
print(f"{10000/(t1-t0):.0f}fps")
t0 = t1
```
Performance on Raspberry Pi Pico W:
Before: ~85fps
After: ~140fps
This also happens to make it compatible with an in-process PR that adds
a fast PixelMap-like class to the core, but which doesn't support
getitem.
