xorgy wrote:Not sure about the magicks behind the Animation Timing Deviation test which cause it to stutter unlike anything else, maybe it's a 2D canvas thing, it doesn't happen with WebGL applications or DOM in my experience. I'm inclined to think that the only thing causing this stutter is poor 2D canvas drawing performance, which I'm more sure of by increasing the number of pixels per plot (and thus the number of individual canvas commands).
Yes, it's the number of individual commands for the graph. The graph uses more draw calls than most TestUFO tests. It runs smoothly at 120fps on my 4K120Hz display on Windows however.
And it's possible your Linux browser may be less forgiving of frame rendertimes:
These are my tests from August 6, 2013. See
my old article. You will observe that Chrome stays perfectly smooth even if drawcalls takes 10ms out of 16ms. To do these tests yourself, add a "&busywait=<milliseconds>" to the TestUFO animation-time-graph URL.
- 1 millisecond busywait
- 2 millisecond busywait
- 3 millisecond busywait
- 4 millisecond busywait
- 5 millisecond busywait
- 6 millisecond busywait
- 7 millisecond busywait
- 8 millisecond busywait
- 9 millisecond busywait
- 10 millisecond busywait
- 11 millisecond busywait
- 12 millisecond busywait
- 13 millisecond busywait
- 14 millisecond busywait
- 15 millisecond busywait
- 16 millisecond busywait
Click on these. One by one. For your Linux browser.
Watch for stutters during graph scrolling.
I can go to 5 or 6 before it stutters at 144Hz.
I can go to 14 or 15 before it stutters at 60Hz.
I can go almost all the way to a refresh cycle length's worth of busywaiting in Windows Chrome, before a SINGLE stutter appears. But some platforms, and some browsers just give up the ghost after 1 or 2 or 3ms of busywait. That makes them particularly sensitive to rendertime fluctuations, and sometimes it's erratic. In Chrome on Windows, with GPU enabled, the browser is darn near
practically guaranteed not to stutter provided the frametime is less than a third of a refresh cycle and is currently in sync with the previous rendertime.
Often, many Linux systems, drivers, window managers, provide an unpredictable environment to guarantee vision science with the browser. Your system is very, very, very good. But what about an average, random system? Even a nearly netbook-era computer now runs 60fps TestUFO fine in WIndows, at least for the simpler tests on TestUFO, thanks to the generous rendertime jitter margin of Chrome. Can we improve Linux all-window-managers-wide, and all-drivers-wide, Intel, AMD, NVIDIA, all of them, to match that? Please?
Blur Busters is offering a $1000 open source bounty for reliable Linux VSYNC in default browser installs on 5 distributions
Option A
Open source bounties offered (up to
USD $1000.00 total -- personal funds out of my pocket -- offer valid through June 31, 2019). The requirements are: Stutterfree in same browser for all configs to 50% refresh cycle rendertimes (busywait is an acceptable simulation of long rendertimes) for 60Hz, 120Hz and 144Hz (and no framecaps, so 240Hz/480Hz allowed but not required as part of bounty), all CPUs/GPUs made in last 5 years, must include Intel/AMD/NVIDIA (all open source and closed source drivers), default Linux distribution install configs of all 5 most popular Linux distributions. Random-chance tests being 90% successful on a sampling of 10 random Linux systems (9 out of 10 randomly chosen Linux combos meeting above criteria 100% skipfree in 15+ second sustains at 8ms rAF() frametimes for 60Hz, 4ms rAF() frametimes at 120Hz, and 3.5ms rAF() frametimes at 144Hz -- and if a rare frameskip occurs on a lightly loaded system, then those single-frame frameskips have to be successfully detectable more than 90% of the time. (occasional False positives OK like 10%-of-time accidentally thinking there was a stutter when there was none -- but there should almost never be false negatives; standard is set at 1% -- only 1% of stutters should go undetected. This threshold is negotiable, however). When claiming bounty, BlurBusters reserves discretion in choosing random Linux systems to test on before awarding bounties (in countries where it is legal) and adjusting bounty for any shortfalls in meeting goals. Qualifying browsers include Chrome or FireFox (can focus on one or the other, or both). Some won't need modification but some will. Currently Windows Chrome is a PASS under this criteria as I can get the TestUFO green-READY guaranteeing frameskipfree operation >90% of the time on a random native-boot Windows system now that meets the "5-years-old-and-newer" criteria on its CPU and GPU. (except for virtual machines -- that's a mess -- don't worry about virtual machines). I can expand this into a more formal list of requirements upon request for interested programmers. We have to clean up the stutterfest mess as much as possible. It's getting better, but not getting better fast enough -- it has to be 90% successful by random chance out-of-box with no further user configuring. I can grab a random Windows system, run TestUFO, and reliably self-detect framedrops 90% of the time in the Chrome browser specifically (which is why I recommend Windows users run Chrome with TestUFO), but I'm impartial to any browser willing to provide reliable data I can act upon. Chrome has always acted fast on 120Hz BugZilla issues so mucho kudos for that specific part. Also, 5-years-and-newer is a generous allowance, because TestUFO runs smooth at 60fps on my decade-old netbook, so I have offered more lenient rules and a lower bar, than the current Windows 7-8-10 situation.
Option B
Help convince all browser vendors or W3C to definitively properly detect missed VSYNC blanking intervals (via a driver standardized way) in a properly configured web browser. Bonus if it also includes something similar to RasterStatus.INVBlank but in a cross platform way. Basically if I can detect existence of native VSYNC support, and I can reliably self-detect framedrops (to notify users about them), and I'm given a frameskip-free guarantee through up to at least 50% refresh cycle busywait. Then I don't have to use useragent discovery to decide if the browser is trusted for frameskip-detection-via-heuristics. I have one commit to my claim,
Section 7.1.4.2 of the HTML 5.2 standard -- collaborating with the W3C in this topic area.
TL;DR: While I do plan to eventually reword the message -- It is an absolutely critical requirement that >90% confidence is made possible before I display a green "READY". Less than 10% of Windows systems have issues like "TestUFO Stuck at 60Hz" and such. I need to get scientific reliability in stutter-detection capability like I can with Chrome under Windows. Hundreds of hours of stutter analysis has been done over the years with browser capability to run perfect TestUFO animations.
Note: Special negotation is available to extend the deadline beyond mid-2019, since I realize it may take a year or more before distributions adopts standards. Random graphics cards, random graphics drivers, random computers containing one of the top5 Linux distributions (top5 will be queried at the end of bounty) -- I realize it takes a long time for fixes to filter through the whole chain (aka good vaccine) before the whole system is sufficiently reliable that a random system is likely to work. Extra funding may be available on special negotiation.
I'm all open to ideas!