Being truer to reality where movement is continuous is not a subjective assessment. It doesn't look different, it looks more like what it's supposed to if realism is the goal. That's not a matter of taste.
As per the post, I wrote this tool to confirm I was getting jerks of ~10ms every few seconds on one USB port and not the other. This would _suggest_ I can catch differences around the ballpark of 100 Hz.
I'm game for a randomized blinded test on 120 Hz refresh rate vs 240 Hz refresh rate. I would indeed be very curious to confirm I can tell the difference with a proper protocol.
Many years back (we were on CRTs), I was in similar shoes, convinced my friend couldn't tell the difference between 60 Hz and 90 Hz when playing video games.
Turns out he only needed to look at the pointer through one push of the mouse to tell right away, successful 100% of the time in a blinded experiment.
As to how you can perceive the difference between 120 events per second and 240, I have what I hope is a fairly simple explanation.
It's like lightning strokes of tens of microseconds making a lasting impression on your perception of the scene. You don't "count" strokes over time, but in space.
When you make circles fast and large enough on screen, you can evaluate the number of cursors that appear before your eyes. At 4 circles per second, is each circle made of ~60 pointers or ~30? Belief not fact: it's not hard to guess.
“If anyone wants to implement this, I think the way to do it is to put the mouse cursor randomly on the edge of a circle whose radius is a few hundred pixels. The randomness is important, though I’m not sure it would be possible to count how many cursors there are.”
And then I realized that doesn’t work, for a few reasons.
One is that you won’t be able to count how many cursors appear during one second. It’ll all look like a jumble.
That leads to the argument that you should place the cursors at a consistent spacing, and the spacing needs to make it so that the cursors stay at the same spot on the screen each loop around the circle.
Unfortunately that doesn’t work either, because you’ll end up seeing a trail of cursors going around a circle once per second, and counting the cursors is hopeless.
So I think you’d need to make a list of the spots on the circle where the cursors should go, then randomly select from them as quickly as possible. That will let each cursor be perceptible because they’ll be spread out over time; the next cursor won’t be just one pixel apart, so this eliminates the “trail of cursors” problem.
I’m still a bit skeptical this could work, but I admit I can’t think of a reason it wouldn’t. You’ll need to be careful, because it’s really easy to fool yourself that you’ve done it correctly when you haven’t.
It would be interesting to make a WebGL canvas and try this out for real. Or maybe just reposition the mouse cursor with Python instead of doing anything graphical.
It seems important to reposition the mouse cursor rather than use WebGL to draw frames, but I think both could work. Actually, the WebGL route would be more faithful to the question of whether gamers specifically can notice 240Hz; there are all kinds of reasons why repositioning the mouse cursor wouldn’t really tell you that. Vice-versa too, because it might be possible to notice when repositioning cursors but not when using WebGL, though I can’t think of why that would be the case.
> Many years back (we were on CRTs), I was in similar shoes, convinced my friend couldn't tell the difference between 60 Hz and 90 Hz when playing video games.
That’s a silly experiment. I could look at a CRT with a completely static image and tell almost immediately whether it was at 60Hz, 90Hz or 120Hz. Flickr at 60Hz was awful, 90Hz was clearly perceptible, and even 120Hz was often somewhat noticeable. And most CRT/graphics card combos would become perceptibly blurry in the horizontal direction at 120Hz at any reasonable desktop resolution, so you could never truly win. Interlaced modes made the flicker much less visible, but the crawling effect was easy to see and distracting.
Yes this a (computer) CRT thing. The commenter might be misremembering the exact numbers, 60 Hz baseline is a flat panel thing, by the mid to late 90s, 75 Hz was something a typical computer CRT would generally aim for and was part of various standards and recommendations.
I’m fairly confident I remember the numbers right. And VESA DMT indeed has 1600x1200 at 60, 65, 70, 75, 85 and 120Hz, and IIRC my old CRT would sync at 144Hz as well with somewhat dubious performance.
It's so many things, starting with the North American electric grid, NTSC, etc.
Yes my graphics card + monitor could theoretically run at more than 60 Hz. When I got to choose between resolution and refresh rate, I picked resolution. Hence 60 Hz.
Yes, I rely on pointerrawupdate. Thanks for letting me know! Unfortunately pointermove is typically synced with graphics in my limited experience, and I think I'd rather not show anything than provide wildly inaccurate numbers.
Although it's for gamepads, it's pretty much indispensable in debugging gamepad-related latency issues. For example, I found that my presumably 1000Hz controller can do only 500Hz in ideal conditions and it starts to drop at a much lower distance from the computer than advertised. Neat stuff.
Of course, that's necessary. Many USB ports "designated" for keyboard and mice are still only USB 1.1, and my post should have said unless on USB 2. You need USB 2 in both the mouse/adaptor and port to get full performance.
Are you talking about R2? If so, requires a credit card, doesn't support atomic deploys or rollbacks, etc.
I'm a CloudFlare user who's used Workers, and trying to sign up for it fails silently here. Bad start for me, doesn't say much, but makes it hard to review further.
That being said, yes, there are competitors. I don't think any offers quite the UX I've built for small teams of experienced developers, but I could be wrong or misguided in my efforts.
