In summary, when rendering a video as a series of frame buffers, before writing pixel/tile value of a rendering buffer frame b, check if it has already been written by frame b-1. This check is done using a hash table. (Are tiles a block of nearby pixels?)
Eg: the tiles for the tree trunk may stay constant and there is no need to re-write them.
A key assumption made is that the hash table lookup (which is buffered/cached) is much faster than file or display IO.
Split_Personality_Computer
I actually came across this concept in 112 when I noticed the term "dirty rectangle" in tkinter documentation. I think dirty rectangles work by basically keeping a list of the bounding boxes of what you've drawn on your screen, and only updating parts of the screen where bounding boxes have changed location or you need to update. This concept works best when you are dealing with sprites (simple 2d with clearly defined bounding boxes)
In summary, when rendering a video as a series of frame buffers, before writing pixel/tile value of a rendering buffer frame b, check if it has already been written by frame b-1. This check is done using a hash table. (Are tiles a block of nearby pixels?)
Eg: the tiles for the tree trunk may stay constant and there is no need to re-write them.
A key assumption made is that the hash table lookup (which is buffered/cached) is much faster than file or display IO.
I actually came across this concept in 112 when I noticed the term "dirty rectangle" in tkinter documentation. I think dirty rectangles work by basically keeping a list of the bounding boxes of what you've drawn on your screen, and only updating parts of the screen where bounding boxes have changed location or you need to update. This concept works best when you are dealing with sprites (simple 2d with clearly defined bounding boxes)