Just click and look at the FPS:
https://project-f.github.io/

For me, Fx 84, it's between 21~25FPS, noticeably slow.

Tested on Edge and Vivaldi, two Blink browsers, smooth, stable at 30FPS.

The surprising thing is: tested in Fx 52 and it's also stable at 30FPS!

Tried 86 Nightly, safe mode... always 21~25.

Very strange such performance regression compared to a version from almost 4 years ago.

My setup:
Windows 10, Ryzen 5 1600, 2x8GB DDR4, Radeon RX 570.

mozregression
2017-06-01 -> good
2017-06-02 -> bad

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bdb2387396b4a74dfefb7c983733eed3625e906a&tochange=aeb3d0ca558f034cbef1c5a68bd07dd738611494

I was trying to record a Profile, but I noticed that when I click to start recording, FPS goes up to 30FPS. Then I click to stop recording and FPS drops back to 21~25FPS. Somehow, it seems that Profiler disables what caused the regression.

(In reply to tustamido from comment #1)

mozregression
2017-06-01 -> good
2017-06-02 -> bad

https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=bdb2387396b4a74dfefb7c983733eed3625e906a&tochange=aeb3d0ca558f034cbef1c5a68bd07dd738611494

Thanks for the regression range! It's quite a lot of stuff but my naive look at the pushes makes me think maybe those from bug 1363829 could be related (especially given your comment 2). Or maybe those associated with bug 1365307?

I'm going to ask the performance team if they can take a look. Kim, sorry, I forget what bug flags to set here to ensure this is triaged. Can you help?

Hi Kim, As part of the triage, can you set the Severity of this bug? Thanks!

(In reply to Andrew Overholt [:overholt] from comment #3)

Thanks for the regression range! It's quite a lot of stuff but my naive look at the pushes makes me think maybe those from bug 1363829 could be related (especially given your comment 2).

I agree with that assessment.

The game relies on setTimeout / setInterval for precise frame scheduling. This is not a good idea in general, because by default, the timer resolution on Windows is really bad. However, if websites keep doing it, and if other browsers work fine, we'll have to do something about it.
I think there are two potential reasons why bug 1363829 may have made this worse:

1. It might have stopped us from telling Windows to enable higher-resolution timers, or
2. It might have resulted in worse setTimeout accuracy in scenarios where timer resolution is already bad to begin with.

I noticed that starting Profiler with the following code restores de good FPS (30) while the Profiler is running:
Services.profiler.StartProfiler(1, 9, []);

But that one doesn't fix:
Services.profiler.StartProfiler(1, 10, []);

The second argument is the interval in ms, right? So maybe Fx default (without Profiler) is 10+, but it should be a maximum of 9ms.

(In reply to tustamido from comment #8)

I noticed that starting Profiler with the following code restores de good FPS (30) while the Profiler is running:
Services.profiler.StartProfiler(1, 9, []);

But that one doesn't fix:
Services.profiler.StartProfiler(1, 10, []);

The second argument is the interval in ms, right? So maybe Fx default (without Profiler) is 10+, but it should be a maximum of 9ms.

This is the profiler changing the timer accuracy for sampling intervals < 10ms. I will remove this in bug 1703410 soon, so that profiling doesn't disturb timer behavior as much.
If you need to profile ASAP, remove the above lines and the end-of-profiling counterpart.

This is the profiler changing the timer accuracy for sampling intervals < 10ms. I will remove this in bug 1703410 soon, so that profiling doesn't disturb timer behavior as much.

Confirmed in latest Nightly. After bug 1703410 there's no way to get the expected performance (30FPS), not even by starting the Profiler.

It should be noted that this bug isn't restricted to https://project-f.github.io. It seems to affect every implementation of emulators with web technologies. Example (DOSBox/Windows 3.1):
https://archive.org/details/win3_molesquest

Is there any workaround for this issue available using about:config or other methods?

(In reply to xaxojon572 from comment #11)

Is there any workaround for this issue available using about:config or other methods?

I'm not sure if you're referring to the main issue of the bug (webgame performance regression), or the profiler issue (that hides the problem when running).
In case it's the profiler one: about:profiling now has an option "No Timer Resolution Change" that won't influence the timer resolution anymore, so the profiler may be used to investigate the main performance regression.

A simple setInterval → requestAnimationFrame fixed the low fps in the game [see https://github.com/Project-F/F.LF/issues/15#issuecomment-879327613], so I guess we can say for sure that this regression is caused by poor accuracy of Fx implementation of setInterval. Reinforcing that this bug was introduced in Fx 55, it's a regression.

I guess that the poor performance of web emulators is also caused by the bad code choice of using setInterval instead of requestAnimationFrame, but anyway this is something that should be fixed in Fx code, since this issue is not reproducible in other browsers.