5 ms·
The problem is that it requires some analysis on the device, and I really want the code to be the less intrusive as possible. I will have a look on how to do it
by owulveryck 3y ago
The problem is that it requires some analysis on the device, and I really want the code to be the less intrusive as possible.
I will have a look on how to do it in a cheap way
- zachallaun 3y agoA naive approach that may still work well is to simply break up the image into fixed, predetermined regions. I don't believe this would be significantly more work for the server if it's already comparing pixel-by-pixel, and the average frame will probably contain updates only in one region. Even breaking it into 4 or 6 would, I think, be a significant payload reduction.
- Evidlo 3y agoIn the repo I linked somehow they get this "damage" information from the Linux kernel where it's already being computed.
- owulveryck 3y agoI will have a look, but at first sight it looks like the repo you mentioned is for reMarkable first version which is using a kernel based implementation of the Framebuffer. It is a bit different for reMarkable2 as the framebuffer is managed by the main process