Closed Roger-random closed 3 years ago
Design change in the spirit of Arduino of keeping API simple
Original plan was a very powerful and flexible system for frame buffer management.
New plan is a double-buffer implementation where the user doesn't have to worry about managing frame buffers. They can keep drawing just as they have before and everything just works. Some performance is left on the table with this model, but ease of use was deemed more important than raw power.
Now with double-buffering there is more time available to draw each frame, and there will never be visible flickers. If a frame takes too long to draw, the previous frame will continue to be shown. There may be a stutter in animation, but that is far better than visible flickers.
Additional behavior change:
waitForFrame()
was highly recommended but not strictly necessary. Without calling it, sketches could still put things on screen. They will look terrible but updates will be visible in some form.waitForFrame()
is required. Nothing at all will update on screen if it is never called.Initial implementation in d1453a394467b73a9dcd39e8f2d31d09240fa410 with further refinements to follow.
When
video_isr()
renders beyond_active_lines
it should be safe for us to swap out the_lines
frame buffer pointer for another. This mechanism will allow functionality like double-buffering, which completely eliminates video tearing, compared towaitForFrame()
which could only reduce it.Software design questions for this advanced scenario:
video_isr()
to send this notification?Related: