Bugzilla

Put another way: it seems that low values for  `layout.frame_rate` just cause these particular animations to play in "slow motion" (and hence take forever) rather than playing at regular-speed-with-fewer-frames.

I do see how that's annoying, but that's unfortunately a side effect of the way that the site/library has written these particular animations (with `requestAnimationFrame()`, and neglecting to account for how much time may have passed between frames).

It's not something that Firefox can really intervene to fix, unfortunately. We can't jump rapidly to the end of the animation because we're not even exactly aware that there's an animation happening; the site is just asking us to run some (different) JS every time that we're ready to paint, and we're dutifully doing that, while also respecting the user's wishes to paint at a lower frame rate (so we're running the site's JS less often than they might expect).

A well-designed site would keep track of how much time has passed since the last callback happened, to ensure that the animation completes in a predictable amount of time, but unfortunately they don't seem to be doing that here, and instead they're just manually updating the positions of their content a little bit on every frame.

Describing the symptom that I'm seeing another way: it seems that low values for  `layout.frame_rate` just cause these particular animations to play in "slow motion" (and hence take forever) rather than playing at regular-speed-with-fewer-frames.  Is that the issue you're seeing as well?

I do see how that's annoying, but that's unfortunately a side effect of the way that the site/library has written these particular animations (with `requestAnimationFrame()`, and neglecting to account for how much time may have passed between frames).

It's not something that Firefox can really intervene to fix, unfortunately. We can't jump rapidly to the end of the animation because we're not even exactly aware that there's an animation happening; the site is just asking us to run some (different) JS every time that we're ready to paint, and we're dutifully doing that, while also respecting the user's wishes to paint at a lower frame rate (so we're running the site's JS less often than they might expect).

A well-designed site would keep track of how much time has passed since the last callback happened, to ensure that the animation completes in a predictable amount of time, but unfortunately they don't seem to be doing that here, and instead they're just manually updating the positions of their content a little bit on every frame.

Describing the symptom that I'm seeing another way: it seems that low values for  `layout.frame_rate` just cause these particular animations to play in "slow motion" (and hence take forever) rather than playing at regular-speed-with-fewer-frames.  Is that the issue you're seeing as well?

I do see how that's annoying, but that's unfortunately a side effect of the way that the site/library has written these particular animations (with `requestAnimationFrame()`, and neglecting to account for how much time may have passed between frames).

It's not something that Firefox can really intervene to fix, unfortunately. We can't jump rapidly to the end of the animation because we're not even exactly aware that there's an animation happening; the site is just asking us to run some (different) JS every time that we're ready to paint, and we're dutifully doing that, while also respecting the user's wishes to paint at a lower frame rate (so we're running the site's JS less often than they might expect).

A well-designed site would keep track of how much time has passed since the last callback happened, to ensure that their JS-animation completes in a predictable amount of time, but unfortunately they don't seem to be doing that here, and instead they're just manually updating the positions of their content a little bit on every frame, which means a slow frame rate means a slow-motion effect.

Describing the symptom that I'm seeing another way: it seems that low values for  `layout.frame_rate` cause these particular animations to play in "slow motion" (and hence take forever) rather than playing at regular-speed-with-fewer-frames as a user might intuitively expect.  Is that the issue you're seeing as well?

I do see how that's annoying, but that's unfortunately a side effect of the way that the site/library has written these particular animations (with `requestAnimationFrame()`, and neglecting to account for how much time may have passed between frames).

It's not something that Firefox can really intervene to fix, unfortunately. We can't jump rapidly to the end of the animation because we're not even exactly aware that there's an animation happening; the site is just asking us to run some (different) JS every time that we're ready to paint, and we're dutifully doing that, while also respecting the user's wishes to paint at a lower frame rate (so we're running the site's JS less often than they might expect).

A well-designed site would keep track of how much time has passed since the last callback happened, to ensure that their JS-animation completes in a predictable amount of time, but unfortunately they don't seem to be doing that here, and instead they're just manually updating the positions of their content a little bit on every frame, which means a slow frame rate means a slow-motion effect.

Describing the symptom that I'm seeing another way: it seems that low values for  `layout.frame_rate` cause these particular animations to play in "slow motion" (and hence take forever) rather than playing at regular-speed-with-fewer-frames as a user might intuitively expect.  Is that the issue you're seeing as well?

I do see how that's annoying, but that's unfortunately a side effect of the way that the site/library has written these particular animations (with `requestAnimationFrame()`, and neglecting to account for how much time may have passed between frames).

It's not something that Firefox can really intervene to fix, unfortunately. We can't jump rapidly to the end of the animation because we're not even exactly aware that there's an animation happening and we don't know what the end state will be; the site is just asking us to run some blob of JS every time that we're ready to paint (with the state-of-the-word changing arbitrarily on each callback), and we're dutifully doing that, while also respecting the user's wishes to paint (and hence run this JS) at a particular reduced frame rate.

A well-designed site would keep track of how much time has passed since the last callback happened, to ensure that their JS-animation completes in a predictable amount of time, but unfortunately they don't seem to be doing that here, and instead they're just manually updating the positions of their content a little bit on every frame, which means a slow frame rate means a slow-motion effect.