WebGL application speeds up while Profiler is running

I’ve been profiling this application in Firefox, and while graphics performance was way worse than on Chromium-based software, I noticed that it gets a significant speed boost while the performance profiler is running. Any idea why? I use the 70.0.1 version on Windows 7.

There is no good reason why profiling makes rendering faster :confused:, but rather the opposite as sampling takes time. Does the same happen when you profile using the extension from profiler.firefox.com/ ? Maybe you can share a profile (via the Publish button in the recording)

1 Like

Looks like we got earlier reports on games using setTimeout for scheduling: https://bugzilla.mozilla.org/show_bug.cgi?id=1566900#c15 . Profiling your game, it seems to use rFA, but are you using the high-resolution argument that the callback gets or something else?

The same happens with the extension (here’s a profile https://perfht.ml/35UN6tw ) , and I’m using Date.now for timing.
But I think I got the issue completely backwards. rAF might have a lower priority while profiling, so more game ticks can run, therefore the gameplay speeds up, not the rendering. Locking the rendering to the game loop seems to ‘solve’ the issue.
Sorry for the confusion and thank you for the response.

I think i’ve figured this one out.

it seems to be a timer resolution issue. the windows firefox virtual machine seems to have a dynamic timer resolution feature. Running the profiler forces the timer resolution up so it can sample at 1 ms.

problem is trying to sleep doesn’t force the timer resolution up. so you can easily lose an entire frame. because the timer resolution is too low, the delay extends too long, and the chance to present the animation frame is missed.

emscripten_sleep() definitely trips this badly, but only on windows desktop firefox. it works just fine everywhere else.

We believe the specific issue you described is now fixed in recent versions of Firefox Nightly, when not on battery. Could you please double check?
The relevant bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1826224.