3 ms·

I just don't see this as a viable option for plug and play usage in a modern desktop environment. Something like this could be used with a bespoke UI optimised

by yarg 3y ago

I just don't see this as a viable option for plug and play usage in a modern desktop environment. Something like this could be used with a bespoke UI optimised around office productivity. In such an environment, complete screen changes (such as after clicking next) don't need to be instant, and minor text changes as well as mouse movements can be fast enough. But that's not the software stack we built for the world - so what's the use case here?

jrockway 3y ago
I'm not so sure. I used to use a 30Hz display while waiting for a driver update (was a 4k early adopter), and I found programming with a 33ms key latency to be maddening. Even 60Hz feels slow if you've used higher refresh rate devices. (I wrote a toy editor with imgui and tried it on my 360Hz monitor vs. my 60Hz monitor and the smoothness was wonderful; high refresh is good for more than just shooting people in a game, though that's why I have that particular monitor.) e-ink displays are nice, but I wonder if it's just because how contrast works? The software asks for #000000 text on a #FFFFFF background, and with e-ink, that's maybe a handful of stops apart. But if you do that on an HDR display, maybe it's twice as many stops apart. The solution might be to ask for #555555 text on a #AAAAAA background, or something like that. (I dark mode everywhere, so I'd do the opposite. In fact, I do do that, my terminal background is not black, and my text is not white. I pick like grey10 and grey90.)
- pbmonster 3y ago
  > I'm not so sure. I used to use a 30Hz display while waiting for a driver update (was a 4k early adopter), and I found programming with a 33ms key latency to be maddening Because of stupid software licences, I have to work a lot in remote desktop when I'm working from home. So I work with latency while typing all the time. It was maddening in the beginning, but I got used to it quickly. I think the key is that you have to be able to touch-type without relying on close-loop feedback. If your error rate is low enough, you quickly learn to trust your fingers. After that, all you need to relearn is cursor positioning - you can't hold down arrow keys (or HJKL in vim) ever. It forced me to rely on moving the cursor x words/paragraphs at a time, and to use the mouse a little more.
- yarg 3y ago
  Just because the individual pixels have a Xhz frequency, doesn't mean that the whole screen has to - depending on how you do updates. I could, for example, update a different quarter of the screen at (4 * X)hz, which would introduce a bit of temporal blurring, but would normalise reasonably fast. With something like a cursor movement, they're often blurry anyway and it's not really an issue. With text entry you can drop your latency, but changes would fade in (in quarters like everything else). You wouldn't have to go with 2 * 2 updates, the larger the blocks the more quickly the fade in would start, but also the blurrier the screen would appear. Of course, the smaller the pixel size you're working with, the larger the block size you could reasonably use before things start looking too bad.

by yarg 3y ago

jrockway 3y ago

I'm not so sure. I used to use a 30Hz display while waiting for a driver update (was a 4k early adopter), and I found programming with a 33ms key latency to be maddening. Even 60Hz feels slow if you've used higher refresh rate devices. (I wrote a toy editor with imgui and tried it on my 360Hz monitor vs. my 60Hz monitor and the smoothness was wonderful; high refresh is good for more than just shooting people in a game, though that's why I have that particular monitor.) e-ink displays are nice, but I wonder if it's just because how contrast works? The software asks for #000000 text on a #FFFFFF background, and with e-ink, that's maybe a handful of stops apart. But if you do that on an HDR display, maybe it's twice as many stops apart. The solution might be to ask for #555555 text on a #AAAAAA background, or something like that. (I dark mode everywhere, so I'd do the opposite. In fact, I do do that, my terminal background is not black, and my text is not white. I pick like grey10 and grey90.)

pbmonster 3y ago
> I'm not so sure. I used to use a 30Hz display while waiting for a driver update (was a 4k early adopter), and I found programming with a 33ms key latency to be maddening Because of stupid software licences, I have to work a lot in remote desktop when I'm working from home. So I work with latency while typing all the time. It was maddening in the beginning, but I got used to it quickly. I think the key is that you have to be able to touch-type without relying on close-loop feedback. If your error rate is low enough, you quickly learn to trust your fingers. After that, all you need to relearn is cursor positioning - you can't hold down arrow keys (or HJKL in vim) ever. It forced me to rely on moving the cursor x words/paragraphs at a time, and to use the mouse a little more.
yarg 3y ago
Just because the individual pixels have a Xhz frequency, doesn't mean that the whole screen has to - depending on how you do updates. I could, for example, update a different quarter of the screen at (4 * X)hz, which would introduce a bit of temporal blurring, but would normalise reasonably fast. With something like a cursor movement, they're often blurry anyway and it's not really an issue. With text entry you can drop your latency, but changes would fade in (in quarters like everything else). You wouldn't have to go with 2 * 2 updates, the larger the blocks the more quickly the fade in would start, but also the blurrier the screen would appear. Of course, the smaller the pixel size you're working with, the larger the block size you could reasonably use before things start looking too bad.