(Large numbers of) Neopixel and Dotstar are slow

[rhooper]

Both Neopixel and Dotstar take a lot of cycles to update pixels. There's two different things going on that slow down both. The first is that converting from Int or RGB[W] to the bytearray is complex code that makes updating pixels slow. The penalty for more pixels is O(N) (as one would expect).

The second issue is that when brightness<1, extra work is done during .show() - the bytearray is copied and every pixel value recomputed. This probably also causes unnecessary garbage collection, and has helped me run out of memory later on in runtime through apparent fragmentation.

This technically isn't a core CircuitPython issue, but because it requires a C helper to address, some work is likely needed in CircuitPython to add helpers to speed up these tasks.

[rhooper]

I have done some benchmarking to understand the penalty of using brightness < 1 is significant, especially with larger strips or matrices (the penalty is noticeable even with a single pixel).

When testing 30, 60 and 72 pixel devices, the speedup from using a simple CircuitPython C helper to update the bytearray members was about 5x. Speeding up .fill() could be even more significant, and a helper to do brightness conversions could be equally significantly faster, especially with a preallocated buffer.

[rhooper]

I think I know what I want to do for speeding up NeoPixel and DotStar _setitem() - a pixelbuf class that takes over for (most of) the python bytearray management... specifically handling byte ordering and bpp=3/4 (RGB vs RGBW) itself. It would also probably handle .brightness and do the bytearray brightness calculations itself ... or keep two bytearrays around (optional because of memory) - one with brightness applied and one with original values, updated during setitem. A helper should exist to return an RGB[W] tuple back to the python code during __getitem__.

[tannewt]

@rhooper That sounds amazing! I've been thinking we should factor out a bunch of the code shared between the RGB strip classes. On the non-express boards we'll still have size trouble though it'd be worth it given the speedups.

[rhooper]

My thoughts on how to handle low memory boards is to keep the logic in neopixel and dotstar, but also check if CircuitPython has the pixelbuf helpers present. If present, it'll use the fast implementation, if not, it'll use the pure python.

This will let us exclude the code from boards where it's not useful or doesn't fit.

[tannewt]

Sounds good. We can play around with it. Thanks!

[kevinjwalters]

There's some previous discussion on this on: https://forums.adafruit.com/viewtopic.php?f=60&t=125609&p=630394#p630394

As mentioned, I ended up breaking the encapsulation and writing directly to the array for a bit more speed. I didn't feel too dirty as it was toy code but it's not ideal!

[rhooper]

@ladyada Later on after today's call a number of us got stuck in a loop about the best way to name and release the pixelbuf work. It was felt that you would have preferences as to what approach to take.

Option 1 is to have a new set of libraries that don't try to be backwards compatible with neopixel.py and adafruit_dotstar.py instead focussing on an API that is mostly compatible but designed for speed.

Option 2 is to do everything possible to make it completely backwards compatible, so that the new libraries are drop-in replacements for the old ones.

Option 3 is some other combination.

My WIP current code uses these names/class hierarchy and repos/branches:

CircuitPython - https://github.com/rhooper/circuitpython/tree/pixelbuf-resync
Class: pixelbuf.PixelBuf
Also has pixelbuf.ByteOrder classes and subclasses for most byte orders, including things like LRGB and variants (for luminance, RGB - eg Dotstar).

RGBLED Library - This one is the one we weren't sure about the naming of, because it works for RGB, RGBW, BGR, LRGB, white only, etc.
https://github.com/rhooper/Adafruit_CircuitPython_RGBLED

My current working approach is to have hardware implementation subclasses in live in this repo, for lack of a better place to put them. There was some concern later on the weekly call about having their names be the same as the existing neopixel and adafruit_dotstar ones, especially if we don't maintain backwards compatibility.

Class hierarchy, as the code stands as of writing this:

pixelbuf.PixelBuf - CircuitPython C class
rgbled.RGBLED - Abstract CircuitPython class subclassing pixelbuf.PixelBuf implementing initialization helpers, context managers, repr, etc.
neopixel.NeoPixel - CircuitPython subclass of RGBLED that adds hardware specific support for dotstar.

As implemented right now, there are differences in the APIs, notably the ByteOrder classes and what properties exist on the object (eg n isn't currently present). It is also not currently iterable and there are likely other compatibility issues I'll need to address. Or we could not try :-)

[ladyada]

we use the neopixel library a lot, so if we can at least have a transitionary period where it uses either pixelbuf or the built in pixel manager, with a try/import/except attempt, that would be best.
lets chat with @tannewt when he's back since there's a lot of API changes and it looks like he was part of the discussion. maybe next thursday Jan 3rd meeting if eveyone's around :)

[tannewt]

I think we should aim to be backwards compatible with neopixel and break any weird things with other RGB LED drivers. Most of those differences are a result of bad copy and paste so we should take the hit now to make them uniform.

We should update each individual driver and include the new PixelBuf dependency as needed.

Does that clarify things? Any other issues we need direction on?

[kevinjwalters]

Are there any examples on how to use PixelBuf https://circuitpython.readthedocs.io/en/latest/shared-bindings/_pixelbuf/PixelBuf.html https://circuitpython.readthedocs.io/en/latest/shared-bindings/_pixelbuf/__init__.html

How does this compare memory-wise with the NeoPixel/DotStar libraries for CircuitPython 3.x?