3 ms·
Did you ever look at only transmitting the changed regions of the framebuffer? You can really cut down on data rate that way: https://github.com/pl-semiotics/m
by Evidlo 3y ago
Did you ever look at only transmitting the changed regions of the framebuffer? You can really cut down on data rate that way: https://github.com/pl-semiotics/mxc_epdc_fb_damage https://github.com/pl-semiotics/mxc_epdc_fb_damage
Thats how the rM VNC project does it, but I prefer the UX of your app not needing any client side software.
- owulveryck 3y agoThe 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