New diff-to-previous framebuffer implementation #129
Conversation
rm-hull
changed the title
rm-hull
changed the title
rm-hull
force-pushed
the
feature/improved-framebuffer-performance
branch
from
54e9909
to
e7ac573
Compare
rm-hull
force-pushed
the
feature/improved-framebuffer-performance
branch
from
e7ac573
to
7cfab73
Compare
rm-hull
changed the title
luma/lcd/device.py
Outdated
| self.framebuffer = getattr(luma.core.framebuffer, framebuffer)(self) | ||
| if isinstance(framebuffer, str): | ||
| import warnings | ||
| warnings.warn( |
There was a problem hiding this comment.
can we use the deprecated library for this instead?
There was a problem hiding this comment.
Coverage should increase now to ~ 99% - there were three identical bits of duplication, but the intention is to remove all this on the next major release anyway.
deprecated only gives us the deprecated decorator, but I think this should've been a DeprecationWarning rather than a RuntimeWarning category
There was a problem hiding this comment.
I want to release this as 2.7.0, and then in about a months time, do a 3.0.0 release that just removes the string framebuffer handling altogether
Ditto for luma.oled.
The other display classes (luma.emulator and luma.led-matrix) should not be affected as they dont utilize the framebuffer concept at all
Implementation status
馃煝 ST7735
馃煝 HD44780
馃煝 ILI9341
Notes
For reference bounce.py demo on ILI9341 (SPI bus speed @ 32MHz) run at approx 10 FPS on RPI B4 using the current implementation. For the new implementation, bounce.py is reporting the following FPS for the following segment size:
num_segmentsObviously a segment size of 1 - this is equivalent to the current implementation, but for the others WOW! ... I didn't expect such a huge improvement. The best value for
num_segmentswill largely depend on what the application draws on the screen, but for the bounce demo, having 25 segments appeared to be the sweet spot for maximal frame rate.