User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

I can reproduce this on a Asus T300 Chi tablet, but not the desktop PC. Simple go to testufo.com and you will see Firefox is running at only 30 fps. I can force 60 fps using "layout.frame_rate" but it very stuttery. This also occurs on a completely fresh profile. The bug is not there when going back to Firefox 65.

I'm not sure if this is intended as some sort of power-saving feature or is indeed a bug, but I don't see any reason why it should be running at 30 fps when 60 fps runs fine on this tablet.

Ok I found the solution, it's "performance.low_end_machine". For some reason Firefox 66 considers the tablet a low-end machine, even though it's perfectly capable of 60 fps, whereas Firefox 65 doesn't (and that boolean doesn't exist.)

This looks like an expected result but the developer should decide that.

Yes, this is somewhat expected behavior in that we're deliberately experimenting on early beta and nightly with lowering frame rates. We're doing this because under some circumstances, this leads to better performance (ie faster page loads) because we run layout/paint less frequently. And yes, this will likely have positive power implications, too.

This functionality trips for CPUs with clock speeds under 1.8ghz and 2 or fewer cores. It was deliberately made very naive to start with to be able to evaluate and iterate quickly (rather than spend a lot of time building a complete model of available cpus and various other characteristics, and only then check how effective this is in the wild and/or what the trade-offs are).

It seems to me that, for this ASUS T300 Chi device, we're looking at the base speed of the processor (1.2ghz) even though it has a "turbo" mode that'll go up to 2.9ghz, which would disqualify it from being considered "low-end". There's a technical question here of how we can detect that situation and do better autodetection.

Separately though, I'm curious about 2 things.

The first is, how did you notice this? I'm assuming that, on updating Firefox, loading testufo.com was not the first thing you did with the machine? When/how did you notice it was running at 30fps - using in-browser games, or video, or something else?)

The second is that I'm a little confused by comment #0:

(In reply to lpy750 from comment #0)

I can force 60 fps using "layout.frame_rate" but it very stuttery.

...

I don't see any reason why it should be running at 30 fps when 60 fps runs fine on this tablet.

I'm a little confused here. Does 60fps stutter when using layout.frame_rate to force it, but not when setting performance.adjust_to_machine to false? If so, do you see the same stutter / not-quite-60fps behavior if you have performance.adjust_to_machine set to false and also set layers.acceleration.disabled to true (you may need to restart Firefox for this to take effect) ?

(Note that you probably want to set performance.adjust_to_machine to false rather than setting performance.low_end_machine, which will get overridden by our autodetection the next time you update Firefox, as long as performance.adjust_to_machine is true)

The first is, how did you notice this?

I have it connected to a TV and was watching a Twitch stream. I noticed it didn't look 60 fps. Checking Firefox with MSI Afterburner/RTSS confirmed the video was running at 30 fps.

Does 60fps stutter when using layout.frame_rate to force it

Yes. It's hard to describe without seeing it, but it looks like it's skipping frames every ½ second or so. I guess it's comparable to playing a game using Vsync vs forcing a certain FPS... it will always look smoother with Vsync than forcing a certain FPS limit, if that makes sense. These are the results with the following scenarios:

performance.low_end_machine;false
layers.acceleration.disabled;false
layout.frame_rate;-1
=
NO stuttering.

performance.low_end_machine;false
layers.acceleration.disabled;false
layout.frame_rate;60
=
stuttering.

performance.low_end_machine;false
layers.acceleration.disabled;true
layout.frame_rate;-1
=
stuttering.

performance.low_end_machine;false
layers.acceleration.disabled;true
layout.frame_rate;60
=
stuttering.

Note: layers.acceleration.disabled;true makes the stuttering even worse regardless of "layout.frame_rate".

(In reply to lpy750 from comment #4)

The first is, how did you notice this?

I have it connected to a TV and was watching a Twitch stream. I noticed it didn't look 60 fps. Checking Firefox with MSI Afterburner/RTSS confirmed the video was running at 30 fps.

OK, great. Thanks for the report, the extra info, and esp. testing the different configurations.

So, having discussed this with Mike, some takeaways:

• at a minimum, we need to figure out how to detect these types of devices and not treat them as low-end. I filed bug 1524299 for this.
• it would be nice to not affect selected-tab video playback, esp. where this is offloaded to the GPU (integrated or otherwise). Matt/Markus, Mike said he thinks (based on his investigations for picture-in-picture work) that in principle, video frames should come in at the compositor, and so maybe we could throttle the refresh driver but not the compositor? Would that be a sensible option? Would that also automatically solve the issue with scrolling (which I think normally happens on the compositor only) in bug 1519241?
• Related, per comment #0 and comment 4, forcing software vsync here is not helping perceived perfromance. Would it be better to implement the throttling as was earlier suggested in bug 1519241, namely by skipping some/all hardware vsync "beats" either in the refresh driver or altogether (unless scrolling / playing video) to achieve "half the hardware vsync rate" instead of forcing software vsync + 30fps - Markus? Or should we restrict throttling to situations where we're forcing software vsync anyway, and if so do we know how often that happens? Do we expect it to be a problem that throttling this way wouldn't allow "tweaking" the lower frame-rate (ie "half the hardware vsync rate" is easy but "smoothed 3/4 of the hardware vsync rate" isn't...).

Unrelated to improvements we can make here, to clarify the state of play:

• this throttling is only enabled on EARLY_BETA_OR_EARLIER. So it won't be in 66 release or later beta versions (I think b9 or later or something).
• to turn this off if it's causing you grief on beta, you can set performance.adjust_to_machine and performance.low_end_machine to false.

Hey esmyth, just putting this on your radar. The lower frame-rate stuff was set to be enabled for Nightly and only early Betas, and so it's been exposed to people with what we've been classifying as "low end hardware" on Beta. The releases in the latter half of this Beta cycle will end up disabling the lowering of the frame rate.

For comment 5, Bas and Olli, can you comment on what the best way forward would be here?

Not sure about the best way, but throttling in child process shouldn't be too hard to try.
Basically skip every second vsync coming from compositor.
But no idea how much that kind of setup would help with battery life, since vsync itself would be still running rather often.
Or is the lower rate for performance?

(In reply to Olli Pettay [:smaug] (massive needinfo queue, ping on IRC on anything urgent) from comment #9)

Not sure about the best way, but throttling in child process shouldn't be too hard to try.

Out of curiosity, why specifically the child? Why not everywhere?

Basically skip every second vsync coming from compositor.
But no idea how much that kind of setup would help with battery life, since vsync itself would be still running rather often.
Or is the lower rate for performance?

Yes, the lower rate is mostly meant for performance. Better battery life would be a nice bonus but isn't the immediate aim.

Don't we need high fps on parent side to have good scrolling speed.

(In reply to Olli Pettay [:smaug] (massive needinfo queue, ping on IRC on anything urgent) from comment #11)

Don't we need high fps on parent side to have good scrolling speed.

Well, there's bug 1519241 with some ideas on how to fix that, but also, as noted in comment #5, we could decide to only change the refresh driver and not the compositor - wouldn't that mean scrolling would stop being affected?

(In reply to :Gijs (he/him) from comment #12)

we could decide to only change the refresh driver and
not the compositor - wouldn't that mean scrolling would stop being affected?

Yes, exactly, that is what I was saying in comment 9.
Some checkerboarding might still become more visible though.

Do we have some testcases or web sites which we want to improve this slower fps?
Some web sites using rAF heavily?

Note, child process does in practice end up throttling refreshdriver already if processing a tick is too slow (RefreshDriver timer falls back to normal priority queue). And if compositor is too slow, we skip paints too.

Marking this WFM as this code no longer runs on beta and we're removing it in bug 1519241.