Hi HN, I built FastPlay, a Windows video player focused on the parts of playback people actually notice: fast open, quick first frame, responsive seeking, and simple local playback. A big part of the experience is keyboard-driven control, so keybinds are first-class: space to pause or replay at end, left and right to seek with accelerated hold behavior, subtitle toggle, auto-replay toggle, fullscreen, zoom, rotation, and fit-to-screen controls. It is still early, but there is already an MSI installer so it is easy to try on Windows. I would especially love feedback on startup speed, seek responsiveness, playback feel, and whether the keyboard-first direction makes sense.
That’s a really good framing. I agree the driver was real-world operator endurance (military/industrial), not consumer preference. In those contexts, “fatigued operator misses something” is a real failure mode, so readability/comfort gets treated like performance.
Also +1 on photoreceptors. The rods/cones split and sensitivity shifts in low light are a big part of why certain wavelengths and lower absolute luminance can feel disproportionately readable at night. I’m less confident that “slow reaction” is the main fatigue reducer (persistence trades off smear vs flicker/visibility), but the broader point about temporal characteristics affecting comfort is spot on.
Good catch. The utm_source=chatgpt params were accidental from a copied link format, and I’m removing them. For transparency: I used an LLM for proofreading and phrasing/formatting only. The research and argument are mine.
100%. The “high contrast” obsession makes sense for daylight and media, but it’s rough for long-form text at night.
I think a lot of the fatigue is absolute luminance and black level, not just contrast ratio. Modern panels often can’t get dim enough (and their lowest backlight still isn’t “dark”), so you end up fighting the display. Your approach of boosting for sun and going below the monitor’s nominal minimum at night is basically what an ergonomic default should do.
Out of curiosity, what app are you using to go below the monitor’s stated minimum?
Totally. That matches how I’ve been thinking about it too: green was a “most visible per unit beam energy” choice, so you got usable contrast even when the trace/text got thin or you were operating near the limits. With a dimmer phosphor you’d just lose the signal.
Also agree on the “commodity default” point. Green was the cheap bright workhorse for a long time, and amber felt more like an option when manufacturers could justify it (and when the use case was heavier on text comfort vs max visibility). Your vector monitor anecdote is exactly the kind of real-world constraint story I was trying to get at.
And yeah, high-end scopes were a different world: once you’re optimizing instrumentation, you start paying for different phosphors/persistence/sharpness tradeoffs instead of the mass-terminal defaults.
Fair. The title is a bit clickbaity. The more accurate claim is: a lot of CRT choices were constraint-driven (power, heat, phosphor efficiency, flicker, tube life), and those constraints often produced more readable, lower-fatigue defaults than some modern “max brightness/high contrast” settings. What fascinated me is how often those engineering constraints ended up lining up with human biology. Also yes, being younger in 1988 probably masked a lot of strain that shows up fast now.