Different implementation strategies for framebuffering
Compare the current frame to the previous frame and tries to calculate the differences: this will either yield nothing for a perfect match or else the iterator will yield one or more tuples comprising of the image part that changed along with the bounding box that describes 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.
- num_segments (int) – The number of segments to partition the image into. This generally must be a square number (1, 4, 9, 16, …) and must be able to segment the image entirely in both width and height. i.e setting to 9 will subdivide the image into a 3x3 grid when comparing to the previous image.
- debug (boolean) – When set, draws a red box around each changed image segment to show the area that changed. This is obviously destructive for displaying the actual image, but intends to show where the tracked changes are.
Calculates the difference from the previous image, returning a sequence of image sections and bounding boxes that changed since the previous image.
the first redraw will always render the full frame.
Parameters: image (PIL.Image.Image) – The image to render. Returns: Yields a sequence of images and the bounding box for each segment difference Return type: Generator[Tuple[PIL.Image.Image, Tuple[int, int, int, int]]]
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.