I’m learning micropython as I go. So far I’ve managed to use the display module from picocalc. It seems to work as though it was a framebuffer. Of course it is actually writing to the actual display of the picocalc. (I hope that made sense.) What I’ve found it that this doesn’t seem to be any faster than using commands in mmbasic to do similar things. I suspect that the bottleneck for speed is the actual display. Is there a different method to do graphics for micropython? Maybe an actual frame buffer?
Whether framebuffers are faster than writing to the display piecemeal depends all upon whether a ‘dirty rectangle’ system is being used, and what percentage of the data being written to the display actually needs to be updated, versus the overhead of sending commands to specify many small windows to be written to (when doing so piecemeal).
If you are writing out the entire display or a significant portion thereof when you only need to update a small portion of it, a framebuffer is likely to be slower.
However, if you are updating every pixel on the entire screen individually, it is generally faster to write the changes into a framebuffer, and then write the framebuffer to the display when you are all done.
I’ll keep that in mind. For now, I’ve got four rectangles and three circles. the circles are almost continuously being update because they represent moving balls. The rectangles are walls that only get updated
When struck by the balls.
What you said makes me wonder if I’m updating the location of the balls too often. I’ll play with that.
Anyway, I appreciate the input.
Robert
One thing I should note is that a framebuffer is necessary in many cases to avoid flicker, e.g. when drawing multiple overlapping objects. With a framebuffer you can draw everything to it and then only update the screen at once when you are done, whereas without a framebuffer the user will see the intermediate, partially drawn states.
That explains the issue with the vertical rectangles. They exhibit what you are describing.
Robert