Update frame buffer pointer upon completion of rendering a frame

[Roger-random]

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 to waitForFrame() which could only reduce it.

Software design questions for this advanced scenario:

• How will the developer submit a new frame buffer pointer in preparation for this swap?
• How will the developer know the swap is complete? Once complete they can safely start rendering to the previous buffer.
• What is a fast but ISR-safe way for video_isr() to send this notification?

Related:

• Double (or more) buffering will require a lot more memory, and the developer needs control over memory. This will either require #3 or a superset of that functionality.

[Roger-random]

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:

• Before this 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.
• After this change, waitForFrame() is required. Nothing at all will update on screen if it is never called.

Initial implementation in d1453a394467b73a9dcd39e8f2d31d09240fa410 with further refinements to follow.