1824472 - Timeouts not working under 150ms

Status: NEW

(Core :: DOM: Core & HTML, defect)

Description

[achaikovsky]

Attachment: fftest.html

Steps to reproduce:

Create an interval with anything under 150ms. Like 10, or 5 ms. Animate an object to move.

Actual results:

It doesn't fire often enough - too slow - delayed.

Expected results:

Faster movement, on time movement.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Core::JavaScript Engine' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 2

[Brian Birtles (:birtles, Feb 26~ parental leave)]

For what it's worth, I can't reproduce this (nor should setTimeout be used for animation).

In any case, there are no CSS animations/transitions in the test case, only JS animations, so I'm moving this to DOM for now.

Comment 3

[Alice0775 White]

I can reproduce this on Nightly 113.0a1 Windows10 w/ clean profile.
Both the upper and lower boxes move slowly at the same speed.

Interestingly,
When Gecko Profiler is running, it seems to work as expected.
The upper box moves faster than the lower box like Chrome.

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

achaikovsky, is this a regression? Did this used to work earlier versions of Firefox?

jlink, can you reproduce this on windows? Comment 3 hints that this is about the high resolution timers.

Comment 5

[Alice0775 White]

Good build : The upper box is x1.5 faster than the lower.
Bad build : The upper and lower box is same speed.

In both build, the speed is increased by circling the mouse pointer on top of the contents until bug 1767396 is landed.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=83f3573ea26840208086aa5bd7d41aff37a0ddf1&tochange=7c6116ac71e954805dccf3146d6fffcf28bbc0cf

Regressed by: Bug 1363829

Comment 6

[Justin Link]

As Olli mentions, the fact that the problem goes away when the profiler enabled suggests very strongly that the current usually-low-resolution timers on Windows (which affect thread scheduling) are likely at play here.

I am currently doing some work related to internal timers in Firefox (which are related to the setTimeout calls in JS but are used for much more) and part of that work involves increasing the timer resolution on Windows (at least when there is good reason to do so) which should "solve" this problem. (I say "solve" because, as mentioned above, this isn't the recommended way to do animation and there will still be some situations under which we will use low-res times on Windows, such as when running on battery power.)

@birtles: You mentioned that the problem did not reproduce for you. Would I be correct in thinking that you are not on Windows?

Comment 7

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to Justin Link from comment #6)

@birtles: You mentioned that the problem did not reproduce for you. Would I be correct in thinking that you are not on Windows?

Sorry, I possibly misunderstood the test case. I am on Windows 11 / Nightly and I observe both boxes moving smoothly but perhaps the expected results are that the two boxes move at different rates?

Comment 8

[Justin Link]

(In reply to Brian Birtles (:birtles) from comment #7)

(In reply to Justin Link from comment #6)

@birtles: You mentioned that the problem did not reproduce for you. Would I be correct in thinking that you are not on Windows?

Sorry, I possibly misunderstood the test case. I am on Windows 11 / Nightly and I observe both boxes moving smoothly but perhaps the expected results are that the two boxes move at different rates?

Ah yes. That is correct. If both boxes are moving at the same speed that is the incorrect result. And you saw that behavior on Windows, which is also as expected.

Comment 9

[achaikovsky]

(In reply to Brian Birtles (:birtles) from comment #2)

For what it's worth, I can't reproduce this (nor should setTimeout be used for animation).

In any case, there are no CSS animations/transitions in the test case, only JS animations, so I'm moving this to DOM for now.

What do you recommend for animation?

Comment 10

[Brian Birtles (:birtles, Feb 26~ parental leave)]

(In reply to achaikovsky from comment #9)

What do you recommend for animation?

Preferably declarative CSS animations, CSS transitions, or Web Animations since these are able to be the most heavily optimized by the browser. When that is not possible, requestAnimationFrame will give better results than setTimeout.

Comment 11

[achaikovsky]

(In reply to Brian Birtles (:birtles) from comment #10)

(In reply to achaikovsky from comment #9)

What do you recommend for animation?

Preferably declarative CSS animations, CSS transitions, or Web Animations since these are able to be the most heavily optimized by the browser. When that is not possible, requestAnimationFrame will give better results than setTimeout.

Hi Brian, thanks for the reply.
We can't use CSS to animate in this case because the webapp we're building is a smooth-moving timeline with calls that get redrawn as it moves. It would require a great amount of rewriting to get the calls to stay rendered and animated with CSS, so unless that becomes the only option, we will have to explore alternatives.
I will give requestAnimationFrame a deeper read as it may be applicable to what we're doing.

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:nika, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 13

[Nika Layzell [:nika] (ni? for response)]

Sending a ni? to gerald to see if there's something we want to do here. In general, we are trying to coalesce timers more going forward to improve battery usage, so I don't know if this is something we're going to want to be changing.

Marking as s2 for now, but we can perhaps shift it back to s3 once we have the direction figured out.

Comment 14

[Florian Quèze [:florian]]

Forwarding Gerald's needinfo to Justin who took over Gerald's timer work.

Comment 15

[BugBot [:suhaib / :marco/ :calixte]]

Set release status flags based on info from the regressing bug 1363829

Comment 17

[Marco Castelluccio [:marco]]

Long standing regression with few duplicates, and the behavior is following the spec, let's downgrade to S3.