Limited to early testers for now, but coming to the public soon.
Why was this ever a hardcoded limitation?
Submitted 9 hours ago by BrikoX@lemmy.zip to technology@lemmy.zip
Limited to early testers for now, but coming to the public soon.
Why was this ever a hardcoded limitation?
Because, somewhere, somehow, the operating system probably did not allocate the slices of time for monitor refresh rates to be pushed to hardware that fast… … That or the code didnt give you the option as its internal enums didnt include such high refresh rates.
Take your pick, either are legit things that could have been the reason and are very normal things to come across in this scenario
Shouldn’t be enums as refresh rates can be floating-point and in practice there also is a lot of weirdness out there, like 59.94Hz.
The timing really needs to be matched to the monitor, you don’t want a 60Hz monitor using the resources of a 1000Hz monitor at any point. It should also be handled by the gpu and gpu driver more than the os.
I don’t think it’s that easy and I struggle to think of a legitimate reason. To me it seems more like an arbitrary bounds-check on monitor info received via hdmi/displayport. Bad coding for sure, but also potentially a point where people are pushed to newer more problematic versions of windows as the older ones “don’t support new hardware”.
gravitas_deficiency@sh.itjust.works 7 hours ago
What possible benefit does that have? It’s so far beyond the realm of human perception that it feels rather pointless.
Admetus@sopuli.xyz 5 hours ago
The human eye doesn’t work via a pulsed frequency and is working on purely organic electrical signals. Quite a few sensory neurons will spot each frame. Article says the eye can sense up to 20,000Hz.
Redjard@reddthat.com 1 hour ago
If you measure response curves of individual cones and rods you won’t see and of the parameters go below the ms range, probably not even below 10ms. However the retina does receive bright short pulses as longer averaged signals. All the very high Hz vision cases see information of the same “object” spread over many cells in the retina. A trail showing up as many distinct images vs a long smear.
If you couldn’t move your eyes the limit would be lower, but because you can’t the rendering cannot anticipate those effects and emulate them. Motion blur is what happens when you always “anticipate” the eye to remain static. If you could measure eye movement extremely well and react within well under a ms, you might be able to match motion blur to eye movement of a single person. Add a second observer and it already breaks down. Not that our sensors are anywhere remotely near making this possible.
kewwwi@lemmy.world 7 hours ago
that “bigger number better” mindset
gravitas_deficiency@sh.itjust.works 7 hours ago
Redjard@reddthat.com 6 hours ago
It really isn’t. There’s a whole lengthy explanation of it here but tldw motion breaks it. Lower refresh rates leave single images instead of smooth trails, while if you track motion then slower refreshrates make stuff blurry while in motion.
I don’t think the video mentions it, but you could flicker the backlight to make tracked motion smooth, but then eye movements will see many individual images end up on your retina instead of motionblur.
If you wanna wiggle you mouse at high speeds while maintaining image quality, say for fps 180 noscopes, then you will easily see improvements into the 10s of kHz.
DaddleDew@lemmy.world 3 hours ago
One easy way to see this of you are equipped for it is to drag a window around on your desktop at 60hz and then do it again at 120hz. The difference on smoothness is obvious.