Volunteer: Framebuffer.get_rect_raw(x,y,w,h)
Hi Micropython People! You are doing a great job!
I am currently developing a MicroPython Eink-Driver for the popular DollaTek T5 Microcontrollers.
My code heavily depends on the framebuffer lib of micropython.
Eink-Displays are quite slow. So the usual way to deal with them is to make partial updates of the display from the framebuffer: Copying a rectangle of the framebuffer to an rectangle in the display.
So I crave for a framebuffer method
get_rect_raw(x,y,w,h)
which returns the raw pixel information of the given area as a byte stream.
For BW this is easy, but with color/intensity things become complicated, since there are quite different pixel representations.
But I think that the functionality to extract a rectangle of the framebuffer as byte-stream is a nice feature to boost performance. Even if the byte-stream has to be postprocessed for the pixel encoding on the python side it is an order of magnitude faster than to query each pixel independently.
I volunteer to come up with a BW pull request.
I am aware that E-Ink displays are slow and that the framebuffer even queried from python by pixel will never be the bottleneck. But why not make the code better?
Cheers,
Volker
Framebuf module: Test are sloppy
Dear Micropython developers!
Writing tests for my new function Framebuffer.get_rect(x,y,w,h) I oriented myself (as a newcomer) on existing tests: Go to Rome - behave like a Roman.
I was a bit disappointed by the tests for the framebuffer code.
Looking at
https://github.com/micropython/micropython/blob/master/tests/extmod/framebuf1.py
w = 5
h = 16
size = w * h // 8
buf = bytearray(size)
maps = {
framebuf.MONO_VLSB: "MONO_VLSB",
framebuf.MONO_HLSB: "MONO_HLSB",
framebuf.MONO_HMSB: "MONO_HMSB",
}
This code runs. But it is wrong if anybody changes the parameters w and h. It only runs correctly if h is a multiple of 8.
This is because here were tests for horizontal as well as vertical pixel orientation mixed together in one function.
For horizontal pixels it has to be
size = w // 8 * h
and for vertical pixels it has to be
size = w * h // 8
And I asked myself:
- Why did anybody test a single buffer size?
- And why a buffer where one boundary is a power of 2?
Then I started to implement my tests - ongoing!
My parametrized tests have found at least six really nasty errors in my own function and in the tests. Bit banging is error prone!
Cheers,
Volker