When using my reader, sometimes mutations require a full screen invert. Sometimes stuff just seems to change trivially. What governs that? Is that done by the display or driver or higher level code?
The problem with e-ink is that redrawing pixels without cycling leads to ghosting after a few draws. Most displays automatically cycles the entire screen now and then to mitigate this. I guess it's up to software or firmware to detect when to do it.
Show HN: ePaper.js – Easily create an ePaper display using JavaScript and HTML
11–14 of 14 posts
Re: Show HN: ePaper.js – Easily create an ePaper display using JavaScript and HTML
#12When using my reader, sometimes mutations require a full screen invert. Sometimes stuff just seems to change trivially. What governs that? Is that done by the display or driver or higher level code?
Re: Show HN: ePaper.js – Easily create an ePaper display using JavaScript and HTML
#13When using my reader, sometimes mutations require a full screen invert. Sometimes stuff just seems to change trivially. What governs that? Is that done by the display or driver or higher level code?
Re: Show HN: ePaper.js – Easily create an ePaper display using JavaScript and HTML
#14Looks very cool and promising. I'm wondering what's the power draw for the Pi with this one since it "Loads index.html in a headless instance of Chromium, using Puppeteer". Isn't Puppeteer quite a power hungry process? Would it run on Pi Zero with a battery attached and how long would it last with updates once a minute or once every 5 minutes? I'm thinking about possible projects that would not have AC power all the…
The syntax is so similar that you can mostly copy and paste the drawing code between js and the arduino project with only a few adjustments. This has the huge advantage that you can use modern JS dev tools including livereload to get the drawing right while still ending up with native code.
[1] https://www.godberit.de/2019/11/08/Mock-for-ESP8266-graphics...