github-actions[bot]
commented
2 years ago 👋 Thanks for this pull request! Unfortunately, it looks like the automated continuous integration (CI) test(s) failed. These can be tricky to fix so we've written a guide on how to fix them locally. It has pages about running pre-commit locally and another about building the docs locally with sphinx. Thanks for contributing to CircuitPython! If you have more questions, feel free to join the Adafruit Discord and post in #circuitpython-dev.
tekktrik
PaintYourDragon
A current project requires high-speed (full-frame animated) updates on 8 matrices on Raspberry Pi, split across two buses, but currently only manages less than 2 FPS. Since “soft” I2C on Pi is limited to about 200 KHz max, we can’t just crank up the frequency to compensate, so instead this PR proposes a couple of speed improvements:
Applicable to all devices: _init() takes a direct approach to initializing all registers, rather than going through things like the fill() function. Additionally, this now accepts an optional frames= kwarg, which can reduce the initialization to only those frames an application anticipates using (e.g. if doing double-buffered animation, one might only need frames 0 and 1). The changes yield about a 2X speedup if all 8 frames are initialized, or 9X if using just 2 (e.g. frames=(0,1)). This might seem unnecessary, but across 8 matrices it really adds up. This change does require a couple dozen extra bytes, but I’d call it inconsequential, this is only on startup before the application really gets to business.
Applicable to the Matrix class only: image() similarly takes some direct action, rather than iterating through pixel() every time. Yields about a 6X speedup, getting a bit over 10 FPS across 8 matrices, just adequate to be considered animation. This does require a couple hundred bytes extra…but…since image() implies the use of PIL, it’s by definition not running on a RAM-constrained microcontroller, and might likewise be considered inconsequential.