Redjard

Uh, you can’t just use a profile that doesn’t exist

I can though.If all the profiles are garbage it’s beyond saving anyway, a single outlier can be ignored.

The monitor sends you a list of accepted input formats. You can sanity check among the list for any outliers, without online information and without hardcoding limits.

I’d expect any current displayport port to handle very high refreshrates when the resolution is reduced correspondingly. The limit to my knowledge is in bitrate.
I’d also expect connector support to sit in the gpu driver.

A basic sanity-check might be the answer though. Still why not improve it instead of just increasing the number? You could check if the rate is an outlier or there are many profiles offered that climb up to that rate for example.

If you measure response curves of individual cones and rods you won’t see any 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.

Edit: I suppose this would mean if you integrated a display into contact lenses and got the latency right you would max out at lower Hz.

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”.

Why was this ever a hardcoded limitation?

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.