5 ms·

I once played a esoteric video game where you had to interact with a terminal inside a 3d world as part of the gameplay mechanic. It was implemented in unity, a

I once played a esoteric video game where you had to interact with a terminal inside a 3d world as part of the gameplay mechanic. It was implemented in unity, and it featured motion blur when a lot of output was generated. Since then I always wonder if text editors and terminals could actually greatly benefit from motion blur whenever text is moving. The purpose of motion blur is first to make things seems smoother, but mostly to indicate how things are moving on the screen with lower framerates. I think with motion blur you could make text jump way further frame by frame while understanding how text was moving. If you have a word that is bold on screen, you could make it jump half a screen with within a single frame while immediately understanding where it went. Wouldn't that help navigating e.g. huge logs (esp. if they're colored) faster while still having a sense of how far you moved frame by frame? If your terminal outputs so much that nothing of the screen is the same frame by frame, you could also still get a feeling of how much is actually outputted, by how blurry the screen is. Never got around implementing it though, curious what you think!

Woshiwuja 3y ago
I turn off motion blur in every game, would hate it on the terminal lol
CaptainFever 3y ago
Could you be talking about Event[0] by any chance?
mrob 3y ago
Motion blur can help compensate for low framerates if it's (approximately) physically accurate, i.e. temporally oversampled. This is how 24fps movies can look tolerable despite the ultra-low framerate: each frame provides more information about how the contents are moving than just a single unfiltered sample, because you can follow the motion blur trails. This is complicated by computer graphics being gamma corrected. If you average multiple temporal samples together in sRGB colorspace, brightness will vary unrealistically with motion speed. You need to calculate the motion blur in linear colorspace then convert to gamma colorspace before displaying it. And for best results, the image to be blurred should be HDR, with the blurred version mapped to the lower dynamic range of the screen. This best replicates in-camera motion blur, giving you clear trails behind bright points. However, any deliberately introduced motion blur is inferior to just increasing framerate. Your eyes already provide motion blur. Anything added by simulation or camera is unrealistic additional motion blur on top of this.
bravetraveler 3y ago
I can't really speak to the idea of added motion blur; aside from bias - I deplore it. However, with high refresh rate displays ~120Hz+ (and today's performant terminals), I can read logs incredibly well. I can pick phrases out of absolutely constant, non-pausing, streams. These displays are typically touted as for twitch-like FPS gamers, but they're honestly very useful for consuming a large amount of logs. There's of course natural blur that comes with this - the quality of the panel decides how clear. Using Wayland probably helps, output is synchronized by default IIRC.
mgdlbp 3y ago
Glimpses of very fast output can still be read by persistence of vision while staring at one part of the screen (you can still get a sense of what's being compiled at the moment, for example), which added motion blur would defeat. Maybe a terminal feature like `less -w' where a status column shows a (potentially motion-blurred) indicator of the amount scrolled in each frame could make the best out of both use cases. Related personal observation: A higher refresh rate increases the max scroll speed where text tracked with the eyes is clear enough to read, but decreases the legibility of fast output read by persistence of vision. When I tested this – the store employee was rather puzzled at this use case – 60Hz seemed to be optimal. At 120Hz or higher, scrolling text was (edit) less comprehensible at the same output rate. This applied to various panels and drive modes. I've never used a high refresh-rate CRT, but I surmise they don't t differ here, since CRT flicker only reduces motion blur that is itself caused by eyes smoothly pursuing onscreen objects made of stationary frames. Edit: Speaking of scrolling UX, I wish browsers had the option to "overscroll" when paging down, so the unread portion always starts at the top of the screen, as implemented in https://news.ycombinator.com/item?id=36825027 https://news.ycombinator.com/item?id=36825027. You can make less do this with `-c' (not at all evident from the documentation). A userscript, perhaps...

Woshiwuja 3y ago

I turn off motion blur in every game, would hate it on the terminal lol

CaptainFever 3y ago

Could you be talking about Event[0] by any chance?

mrob 3y ago

Motion blur can help compensate for low framerates if it's (approximately) physically accurate, i.e. temporally oversampled. This is how 24fps movies can look tolerable despite the ultra-low framerate: each frame provides more information about how the contents are moving than just a single unfiltered sample, because you can follow the motion blur trails. This is complicated by computer graphics being gamma corrected. If you average multiple temporal samples together in sRGB colorspace, brightness will vary unrealistically with motion speed. You need to calculate the motion blur in linear colorspace then convert to gamma colorspace before displaying it. And for best results, the image to be blurred should be HDR, with the blurred version mapped to the lower dynamic range of the screen. This best replicates in-camera motion blur, giving you clear trails behind bright points. However, any deliberately introduced motion blur is inferior to just increasing framerate. Your eyes already provide motion blur. Anything added by simulation or camera is unrealistic additional motion blur on top of this.

bravetraveler 3y ago

I can't really speak to the idea of added motion blur; aside from bias - I deplore it. However, with high refresh rate displays ~120Hz+ (and today's performant terminals), I can read logs incredibly well. I can pick phrases out of absolutely constant, non-pausing, streams. These displays are typically touted as for twitch-like FPS gamers, but they're honestly very useful for consuming a large amount of logs. There's of course natural blur that comes with this - the quality of the panel decides how clear. Using Wayland probably helps, output is synchronized by default IIRC.

mgdlbp 3y ago

Glimpses of very fast output can still be read by persistence of vision while staring at one part of the screen (you can still get a sense of what's being compiled at the moment, for example), which added motion blur would defeat. Maybe a terminal feature like `less -w' where a status column shows a (potentially motion-blurred) indicator of the amount scrolled in each frame could make the best out of both use cases. Related personal observation: A higher refresh rate increases the max scroll speed where text tracked with the eyes is clear enough to read, but decreases the legibility of fast output read by persistence of vision. When I tested this – the store employee was rather puzzled at this use case – 60Hz seemed to be optimal. At 120Hz or higher, scrolling text was (edit) less comprehensible at the same output rate. This applied to various panels and drive modes. I've never used a high refresh-rate CRT, but I surmise they don't t differ here, since CRT flicker only reduces motion blur that is itself caused by eyes smoothly pursuing onscreen objects made of stationary frames. Edit: Speaking of scrolling UX, I wish browsers had the option to "overscroll" when paging down, so the unread portion always starts at the top of the screen, as implemented in https://news.ycombinator.com/item?id=36825027 https://news.ycombinator.com/item?id=36825027. You can make less do this with `-c' (not at all evident from the documentation). A userscript, perhaps...