1. 30
  1. 12

    The work on latency here is what makes me excited. They seem to have made significant advances on the hardware/display controller side, claiming <120ms latency.

    However, It doesn’t seem like they’ve attempted to optimize things on the software side of things. The demo shows Windows running, I’m curious what an E-Ink aware Linux display server stack optimized for latency could achieve.

    1. 2

      This bit stood out for me:

      Another is to use CMY color pigments inside a single pixel (called ACeP), similar to a color print. This results in much-improved reflectivity compared to CFA solutions, but the downside is increased response time, up to 30 seconds on 1st generation ACeP screens and 1 second on 2nd generation ACeP screens.

      30 seconds to 1 second is a huge increase. I spend a lot of time in the terminal and I’d hate to lose syntax highlighting, but I’d be quite happy with a 0.5 second response time and this implies that I probably don’t have to wait too many more years.

      1. 1

        I’ve been hoping that I can make do with much more minimal syntax highlighting. I’ve experimented with purely monochrome “syntax highlighting” with bold keywords and comments in italics and found it to be a decent improvement over none at all. I think this approach can go pretty far with good choice of font, especially for simpler languages.

        I haven’t tried to switch to it for normal work or tested on actual Eink yet though, so I can’t say if it would be good enough to make the switch worth it for everyday programming.

        1. 2

          I’ve been using low-color syntax highlighting for the past 4+ years, mostly using italics, font weight, underline, and different fonts to highlight stuff, over colors. Works really well, for every language I write in (C, C++, JavaScript, TypeScript, Shell, Scheme, Markdown, etc).

          I found that there are a lot of things I used to have colors for, which really don’t need any highlighting. Reducing the number of things highlighted makes it easier to focus on the important bits, I found. Having to think about what to highlight with the limited set of colors and font properties made the code I look at more understandable, and far less overwhelming.

          I still use some colors other than shades of grey (blue for strings, red & green for diffs, a creamy, slightly yellowish color for highlighting the current selection), but none of those are super important, and I could use something else for them. Once an Eink monitor becomes available and affordable, I’ll be there to try. I’m already halfway there.

      2. 1

        Like remarkable has done to reduce the latency on their eink tablet?

        1. 1

          Got any links to technical writing on their solution?

          1. 1

            I think that is mostly their proprietary special sauce.

      3. 5

        50k units is a lot

        1. 3

          I really hope they are banking on 50k interested people == 2k sales

        2. 5
          1. 8

            You’re right, I didn’t realize that discussion was only 5 days ago. This blog post was published today however and has more technical detail than any of their previous posts so I think there may be new things to discuss.

            1. 1

              Fair point, thanks.

          2. 4

            The Modos Paper laptop mentioned here recently is absolutely something I’d use for coding, though in the situation where I’d use it most I’d need to be sure I had a good light behind my head…

            But yeah, the reduction in eyestrain would be immense, I imagine.

            1. 2

              I wouldn’t like to go back to coding without coloured syntax highlighting, but I’m really enthusiastic if they can do a second-generation with colour. I also mostly care about colour for complete tokens, so if the existing colour eInk displays that can manage 1s updates could work in a non-flashing configuration where they first drew in greyscale and then filled in the colour for text then that would be very interesting (this would probably require some cooperation from the terminal emulator / text view to draw things that have changed in the last frame as black and then draw them as colour if they’ve remained stable for > 500ms or something).

            2. 2

              Alright, this is cool, don’t get me wrong, but: Why e-ink? I too want a frontlighted panel for programming, but I feel like this usecase woul be better served by an e-paper LCD panel. Like Pebble had, but several years newer. My old laptop had a cheaper screen which was decently readable in direct sunlight with the backlight off. A grayscale trasflective panel would IMO be significantly better, as they don’t suffer from e-ink reponse times.

              1. 2

                You’re referring to the Sharp memory lcd panels. I don’t recall them ever selling a large panel let alone with something close to hiDPI. You’d probably need a fairly substantial volume expectation for them to consider making such a thing.

                Compare to the 13.3 eink grayscale panel IIRC has been around in some form for nearly a decade.

              2. 2

                The way it loses contrast during motion, only to sharpen up when the scrolling stops, takes me right back to the days of laptops with passive-matrix STN LCDs :)

                1. 1

                  There are already a few different e-ink monitors and laptops on the market. Of course they are older technology which doesn’t refresh nearly as fast. But they’ve been marketed by big companies, and haven’t been commercially successful yet. I hope Modus figures it out.

                  1. 1

                    I would absolutely not want to use an e-ink display for normal interactive use like coding. Simply scrolling text is a worst-case scenario for those displays. Latency of 100ms is still at least 6x worse than LCDs.