LagIsTooDamnHigh wrote: ↑13 Jun 2021, 19:09
And I can't see evidence of multiple frames being collected in the DLP's "first framebuffer" because of an issue with TestUFO/Browser/VSYNC behaviour?
Browser behavior.
Browsers do not officially properly support VSYNC OFF.
The "VSYNC OFF" mode in browser options is really just triple buffering. It is usually extremely hard to force a browser to do true VSYNC OFF that's not force-triplebuffered.
Browsers are a software DWM-like layer on top of DWM! So when you try to force VSYNC OFF in a web browser (even if your DWM is turned off, like an old copy of Windows XP), the browser software layer is already forcebuffering (DWM style) internally. You must FIGHT a lot of layers just to trick one specific brand of browser to remotely do something resembling true VSYNC OFF with the expected spray of tearlines. It's a very onion layere'd fight.
This is why I complained (a long time ago) in this git text:
https://github.com/w3c/html/issues/375
I've already squealed an advocacy article out on this matter:
VSYNC API access for browsers. I've already made a modification to a HTML standard (git commit for HTML 5.2 section 7.1.4.2 to mandate requestAnimationFrame() matches refresh rate).
With all the success convincing browser vendors to support high=Hz operation (240fps TestUFO is possible thanks to some of my work collaborating in the FireFox/Chromium bug tracking systems), the hill of VRR as well as VSYNC OFF, is a tall hill especially for browser developers more experienced with 60Hz DELL desktop monitors.
My famous
Year 2013 High Hz Browser Tests trailblazed a fair bit of optimizing at multiple browser vendors. Now it's at the point where Chrome is (usually) extremely TestUFO friendly, and so reliable that even
www.testufo.com/frameskipping is trusted by monitor overclockers, because of its ability to self-detect browser stutters.
If you would like to help me do a custom open source Chromium fork to allow me to add support to VSYNC OFF & VRR in a way that is compatible to TestUFO.
...I might create a paid BountySource for you. Yes. For realz. Paid money for you if you can get proper tearlines in a web browser.
For such a BountySource, I could probably budget a BountySource of an approximate ballpark 500 dollars for a true tearline in a web browser, and 1000 dollars for tearlines + VRR. It's a long source of frustration that I can't do TestUFO VRR, nor I can't do TestUFO VSYNC OFF -- because of standards limitations.
For you or other readers reading this -- private contracts are possible (inquire within: mark [at] blurbusters.com) if you've got a well vetted LinkedIn/resume -- but would require it to be open source, in a license compatible with my projects. It's not something Blur Busters currently can afford a full time team for, but can throw a high three-figure or low four-figure budget to incentivize, even if it's a private nonstandardized Chromium fork just to support TestUFO-VRR and TestUFO-VSYNC-OFF modes.
Nominally, my easiest goal is that I'd build a self contained TestUFO.exe that runs the said custom-modified web browser (in a fashion similar to Chromium Embedded Framework), and allow the user to configure VSYNC ON, VSYNC OFF, and VRR.
It's crazy the amount of nonstandard heuristics I need to do in TestUFO, just to detect a single framedrop to automatically invalidate scientifically frame-pacing critical tests such as
www.testufo.com/frameskipping and others ... There's no APIs that tells me a dropped frame.
(P.S. Self aside. Hell, beamracing in JavaScript would be a crazy exercise to abuse a browser for! Assuming there's an added JavaScript call or flag to turn on/off VSYNC (not necessary for the aforementioned bounty, just a bonus)-- then I think I can actually can port my Tearline Jedi into JavaScript via theoretical modified web browser with adequate VSYNC-access APIs. Javascript powered beam racing -- ha, ha. Javascript API to turn VSYNC ON briefly, measure the monitor Hz to an exact amount like I already do at www.testufo.com/refreshrate ... then call theoretical JavaScript API to VSYNC OFF. Then use extrapolated prediction of VSYNC, use now() microsecond counter to decide when to create raster-positioned tearlines. Albiet Meltdown/Spectre timer-fuzzing may kill that precision, though 20 microsecond fuzz still allows me to place tearlines within a few pixels of its intended vertical position. JavaScript performance should be performant enough on lightly loaded systems in theory, running in Performance Mode rather than Battery Saver or Balanced Mode. Though the browser's own power management may still futz things up, like it already sometimes do to TestUFO, making framepacing less precise than it should be in TestUFO.)
For now, standalone executables is the only way to reliably do these sorts of tests. You did the correct move.
/vent (at web browsers)