Different implementation strategies for framebuffering
Compare the current frame to the previous frame and tries to calculate the differences: this will either be
Nonefor a perfect match or some bounding box describing the areas that are different, up to the size of the entire image.
The image data for the difference is then be passed to a device for rendering just those small changes. This can be very quick for small screen updates, but suffers from variable render times, depending on the changes applied. The
luma.core.sprite_system.framerate_regulatormay be used to counteract this behavior however.
Parameters: device (luma.core.device.device) – The target device, used to determine the initial ‘previous’ image.
A sequence of pixel data relating to the changes that occurred since the last time
redraw_required()was last called.
Returns: A sequence of pixels or
Return type: iterable
Realign the left and right edges of the bounding box such that they are inflated to align modulo 4.
This method is optional, and used mainly to accommodate devices with COM/SEG GDDRAM structures that store pixels in 4-bit nibbles.
Calculates the difference from the previous image, return a boolean indicating whether a redraw is required. A side effect is that
imageattributes are updated accordingly, as is priming
Parameters: image (PIL.Image.Image) – The image to render. Returns:
Return type: bool
Always renders the full frame every time. This is slower than
diff_to_previousas there are generally more pixels to update on every render, but it has a more consistent render time. Not all display drivers may be able to use the differencing framebuffer, so this is provided as a drop-in replacement.
Parameters: device (luma.core.device.device) – The target device, used to determine the bounding box.
A sequence of pixels representing the full image supplied when the
redraw_required()method was last called.
Returns: A sequence of pixels. Return type: iterable
Just return the original bounding box without any inflation.