This is specifically about eInk displays. They do not suffer from the problem you are describing.

Generally this is solved by displaying more than one image and rotating between images on a time interval.

This is for both:

> It's designed for both screens that update 60 seconds per frame, and for screens that update 60 frames per second.

Or that's what at least I infer from that, because I don't know of 60 fps eInk displays :).

The article says it can just use the Pi’s HDMI output as a screen, so you could presumably drive that at 60FPS if you want. I imagine the HDMI output is useful for debugging even if you ultimately intend to use an e-ink display.

There's nothing built in now, but a common technique would be to make the image e.g. ~10px larger in each direction, and then choose a random crop every other second.

It should be really easy to build a FrameOS app that does this. Add one node at the start of the render loop to increase the image accordingly, and one at the end to crop it back down. I was planning to use a similar technique to display smooth scrolling animations/slideshows, but it can definitely be used to prevent burnin.

They will generally transpose everything on the screen by a small randomized difference every minute or so.

If your site's always flapping, don't worry about burn in?