You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Frame rate detection was added in this commit:
85ca394
but in a way that only worked in developer.html, and had various bugs.
This change makes automatic frame rate detection work in the same way when the benchmark is run from
index.html and developer.html. The `determineFrameRate` function is moved to
`window.benchmarkController`, and called from the `initialize` functions in both cases; code is
added so that the button to run the benchmark is disabled until detection is complete; a label shows
the detected fps, or an error message in the event of failure.
For historical reasons, `developer.html` initialized `frame-rate` to 5/6 of `system-frame-rate`,
resulting in a targetFPS of 50 when run from `developer.html`, which was different from the
60fps target when run normally. Remove this so that targetFPS always matches system frame rate.
There was a lot of messiness in how targetFrameRate was propagated through the benchmark, and the
analysis functions, with lots of `|| 60` fallbacks. This change removes all those fallbacks, making
errors obvious when we would have silently fallen back to 60. So `options["frame-rate"]` and
`options["system-frame-rate"]` should always be defined. (`system-frame-rate` only differs from
`frame-rate` if the user makes changes in developer.html.)
The analysis functions use `targetFPS` everywhere. `calculateScore` had an insidious bug where we're
try to read `_targetFrameRate` off the wrong `this` object.
When importing an older JS file that does not contain any frame-rate data, assume 60fps (and log).
0 commit comments