original poster wrote:So, i was curious, do we all agree that vsync is a workaround for tearing, and that most of us would rather play with tearing than deal with measurable input lag? yes?
True -- though I must point out for solo gameplay, is not as simple as just tearing. VSYNC ON versus VSYNC OFF also affects microstutter mechanics too. This can be very important for game emulators, or any game that uses ultrasmooth scrolling such as TestUFO. Lots of emulators stutter more with VSYNC OFF, for example. For competitive play, we prefer to not deal with input lag. However, some of us love the image quality of supersmooth motion (e.g. GTX Titan with solo gameplay in Bioshock Infinite, 100fps@100Hz, with blur reduction strobing (ala LightBoost clones) with zero stutters and zero tearing -- looks very pretty when sliding very fast on the aerial rails.
original poster wrote:Why is it then that we do NOT agree on frame pacing as a work around for slight stuttering adding variable input lag dependent on THEORETICALLY stable fps, being forced ALWAYS ON, is just as bad an idea? Is it ignorance on the subject? is it the test that show stationary -> first movement showing no input lag(various tests, including recently done tests by noacc on esreality) undermines the real cause, and the ppl affected.
I believe it "depends". Frame pacing sometimes the lesser of evil (add lag for predictability) or the worse of evil (predictability doesn't improve enough to compensate for lag). This equation appears to changes based on how powerful your GPU is, which game you play, and what refresh rate you are running at. The lag compromise is much smaller in some situations, than others. So for some people, frame pacing can become the lesser of evil, because predictability can make it easier to aim (instead of more stuttery, erratic-aiming at only insignificantly less lag). The (semi-rheoretical) question is really -- how big is the tradeoff?
original poster wrote:war1 wrote:An ON/OFF switch would be the definitive workaround as we do have on VSYNC, since most ppl know how vsync works, some make the choice(most) to not use it. Why not on frame pacing is my big problem.
Taken from esreality, I can prove frame pacing is always on, on my current setup. Windows xp, stalker cop with variable framerate 50-100 gives me oldschool stutter, which is bad, yes, but mouse is snappy nonetheless. Windows 7, same game and variable framerate gives not stutter, but HUGE mouse smoothing, making it really unplayable. Limiting framerate to 35fps with nvidia inspector gives most of the crisp mousefeel back(should in any case)
If you see less stutter and no tearing, then under Windows 7 you may be running in full screen windowed mode which is actually Windows compositing in action (triple buffering effect). One method of solving this is to enable/disable the mouse raw input mode (google "enable mouse raw input windows 7") but several seem to have been able to do tweaks and workarounds to get a similar mousefeel they did under Windows 7.
On a related (but not exactly same subject), it is observed for many games that have massively variable-framerate situations (framerate fluctuates massively), then you may wish to try out a 500Hz or 1000Hz setting, because it creates less aliasing-effects (beat frequency effects = mouse jitteriness/mouse stutter) between the frequency of the pollrate and the frequency of the framerate. This is highlighted in the
Blur Busters Mouse Guide, however, there are situations where 125Hz works really well (especially games like Quake Live). For example, 125Hz pollrate at 40fps, can create approximately three major mouse-induced microstutters a second (120 / 4 = 3). This might actually be the lesser of evil, if your mouse has unacceptable 'filtering' effects at 500Hz or 1000Hz, or becomes a lot less accurate at the high poll rate (can be helped with a better 500Hz or 1000Hz mouse) or can't track fast enough during a 180 degree fast flick (ditto). But in general, when playing games with massively-varying framerates (e.g. 30fps->150fps->70fps->100fps), using an ultrahigh poll rate can feel far more 'locked in' than using 125Hz. On the other hand if you're playing Quake Live at 125fps locked, then 125Hz may actually end up superior, as it would feel very brisk and locked-in.
Also, the high pollrate is also recommended if you're using high refresh rates or motion-improving technologies (120Hz+, or strobing, or GSYNC) since the stuttery-feel of 125Hz poll rate becomes much more apparent with "Better Than 60Hz" technologies...
war1 wrote:Can i record this behavior with software, or do i need a camera pointed at screen?
Tools to analyze mouse feel in a lab-quality way, would be lovely.
A lot of feel is subjective, but the numbers would be very interesting whenever things lagged or got artificailly smoothed.
High speed video can be very helpful.
I wonder if someone, could perhaps invent a test: to measure the accuracy/variability of mouse report in a "button-to-eyeballs" manner that is also measurable via high speed camera (Much like I did for my GSYNC input lag tests). Maybe someone may need to find a way to measure mouse position reports quickly onto a zero-lag display (e.g. LED indicators or a 1000Hz union-jack numeric readout created out of an electronics circuit connected to, say, signal lines of a parallel printer port PCI card), so one can corroborate the mouse reports on a readout (<1ms lag), versus the actual mouse report occuring on the screen (variable lag).
