Hacker News Reader

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

Thats how the rM VNC project does it, but I prefer the UX of your app not needing any client side software.

View on HN

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

A 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.

In the repo I linked somehow they get this "damage" information from the Linux kernel where it's already being computed.

I 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

Reply on news.ycombinator.com