suspect-devices/circuitpython/shared-module/_pixelbuf/PixelBuf.c, branch mainCircuitPython - a Python implementation for teaching coding with microcontrollershttps://git.suspectdevices.com/suspect-devices/circuitpython/atom?h=main2021-03-15T13:57:36+00:00run code formatting script2021-03-15T13:57:36+00:00microDev70126934+microDev1@users.noreply.github.com2021-03-15T13:57:36+00:00urn:sha1:a52eb88031620a81521b937f2a0651dbac2bb350_pixelbuf: Respond to review comments2021-02-24T22:27:09+00:00Jeff Eplerjepler@gmail.com2021-02-24T22:27:09+00:00urn:sha1:dac4ac5d2a294efea12ad8cea6254a94fe4ec765
* Comment on the reason for scaling by 256
* Divide by 256 instead of shifting
* fix a cast; eliminate an unneeded roundf() to get a few bytes code back
_pixelbuf: Increase performance of brightness-scaling2021-02-24T15:51:27+00:00Jeff Eplerjepler@gmail.com2021-02-24T15:29:59+00:00urn:sha1:b7f5c277ad61076848dfc2065bc254092f4dd4ce
On the Pico, this increases the "fill rate" of
pixels[:] = newvalues
considerably. On a strip of 240 RGB LEDs, auto_write=False, the timings
are:
|| Brightness || Before || After || Improvement ||
|| 1.0 || 117 kpix/s || 307 kpix/s || 2.62x ||
|| 0.07 || 117 kpix/s || 273 kpix/s || 2.33x ||
It's worth noting that even the "before" rate is fast compared to the
time to transmit a single neopixel, but any time we can gain back
in the whole pipeline will let marginal animations work a little better.
To set all the pixels in this way and then show() gives a pleasant bump
to the framerate, from about 108Hz to 124Hz (1.15x)
The main source of speed-up is using integer math instead of floating
point math for the calculation of the post-scaled pixel values. A slight
secondary gain is achieved by avoiding the scaling altogether when
the scale factor is 1.0.
Because the math is not exactly the same, some scaled pixel values may
change by +- 1 RGBW "step". In practice, this is unlikely to matter.
The gains are bigger on the Pico and other M0 microcontrollers than M4
microcontrollers with floating point math in the hardware.
Happily, flash size is also improved a bit on the Pico build I did,
going from
> 542552 bytes used, 506024 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
to
> 542376 bytes used, 506200 bytes free in flash firmware space out of 1048576 bytes (1024.0kB).
use the stack2020-08-10T22:42:05+00:00Roy Hooperrhooper@toybox.ca2020-08-10T22:05:13+00:00urn:sha1:1b7709f3250289ac746090306425734a5e4294a3fix trailing whitespace2020-08-10T16:04:44+00:00Roy Hooperrhooper@toybox.ca2020-08-10T16:04:44+00:00urn:sha1:ef1782f85e9020a01658d28708b44444915f74b2make pixelbuf handle floats and iterables2020-08-07T22:42:06+00:00Roy Hooperrhooper@toybox.ca2020-08-07T22:42:06+00:00urn:sha1:e73dba21d26b93ce1140faecb4820ae46ce4c742Allow setting RGBW pixels with RGB tuples2020-05-25T00:35:13+00:00Roy Hooperrhooper@toybox.ca2020-05-25T00:35:13+00:00urn:sha1:dd980249c65ef02a0ebbccea21022a1e34aba2bdSimplify pixelbuf set_pixels function2020-05-23T01:19:17+00:00George Watersgwatersdev@gmail.com2020-05-23T01:19:17+00:00urn:sha1:c592a2b4db112a512b6519fd79f22943b96db40aUse mp_int_t for setting pixelbuf slice indices2020-05-22T20:28:09+00:00George Watersgwatersdev@gmail.com2020-05-22T20:28:09+00:00urn:sha1:f078055f592e01269b1a7648cd05af06b4cc81b5
When handling negative steps, start and stop need to be mp_int_t so they
can be checked against a potential negative value during the for loop
used to set the slice values.
Implement negative step for pixelbuf slices2020-05-22T01:57:45+00:00George Watersgwatersdev@gmail.com2020-05-22T01:57:45+00:00urn:sha1:16ffc731f3c64b36a486a27d87b10742cf5bb4ba