I wonder, is it possible to go even further, split the screen up into smaller pieces, and then compute the hash for each piece and then modify only the pieces that have changed? It would be like calculating just the changes and applying them, though of course, in blocks. In desktop applications for example, if a given app isn't full-screen and only uses up let's say the top left quarter of the screen (a very likely situation in tiled window managers), then I think the benefit of this could be quite nice. And I know that Wayland offers ways of telling the compositor what parts of the app changed. I wonder if they are able to do something similar to reduce overall bandwidth used.
dhua
@rmanne
Isn't that what already happens? If I understand what's happening, the image is split up into tiles, and the hash is computed for each. If the hash for that tile is different next frame, then it is written. So every "red" tile in the images on the slide would be changed.
rmanne
@dhua oh was that the case? I thought, rather than for each tile, rather, do it for the whole image.
Araina
Yes. Here tiles means small rectangles. Those red rectangles on the second image needs to be updated while others can avoid writes.
https://community.arm.com/groups/arm-mali-graphics/blog/2012/08/17/how-low-can-you-go-building-low-power-low-bandwidth-arm-mali-gpus
I wonder, is it possible to go even further, split the screen up into smaller pieces, and then compute the hash for each piece and then modify only the pieces that have changed? It would be like calculating just the changes and applying them, though of course, in blocks. In desktop applications for example, if a given app isn't full-screen and only uses up let's say the top left quarter of the screen (a very likely situation in tiled window managers), then I think the benefit of this could be quite nice. And I know that Wayland offers ways of telling the compositor what parts of the app changed. I wonder if they are able to do something similar to reduce overall bandwidth used.
@rmanne
Isn't that what already happens? If I understand what's happening, the image is split up into tiles, and the hash is computed for each. If the hash for that tile is different next frame, then it is written. So every "red" tile in the images on the slide would be changed.
@dhua oh was that the case? I thought, rather than for each tile, rather, do it for the whole image.
Yes. Here tiles means small rectangles. Those red rectangles on the second image needs to be updated while others can avoid writes.