Need to be appended frame number in NotifyVsync() for Frame Timing API

NEW
Assigned to

Status

()

Core
Graphics
3 years ago
2 years ago

People

(Reporter: hiro, Assigned: hiro)

Tracking

({correctness})

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments, 1 obsolete attachment)

(Assignee)

Description

3 years ago
In Frame Timing API, a number needs in each Performance[Render|Composite]Timing. 
See the spec[1] for more detail.

To number the same value in the same frame VsyncSource should handle the variable.

[1] http://w3c.github.io/frame-timing/#widl-PerformanceRenderTiming-sourceFrameNumber
(Assignee)

Comment 1

3 years ago
Created attachment 8609176 [details] [diff] [review]
Introduce frame number

CompositorSoftwareTimeScheduler number the frame number 0, but I think it's OK because the scheduler will be removed in bug 1133528.

:mchang, can you please give any feedback?
Assignee: nobody → hiikezoe
Attachment #8609176 - Flags: feedback?(mchang)
(In reply to Hiroyuki Ikezoe (:hiro) from comment #0)
> In Frame Timing API, a number needs in each
> Performance[Render|Composite]Timing. 
> See the spec[1] for more detail.
> 
> To number the same value in the same frame VsyncSource should handle the
> variable.
> 
> [1]
> http://w3c.github.io/frame-timing/#widl-PerformanceRenderTiming-
> sourceFrameNumber

I'm not very familiar with the spec, but the patch as is will give each vsync frame number, not necessarily what we composited / painted. For example, if a paint takes longer than 16 ms, we coalesce the vsync messages so you can skip frame numbers sent from the vsync source. Same with the compositor. 

Does the spec say that you want the timing for each actual composite/paint and that they can diverge? Since there are two timing information fields in that spec, one for the rendering and one for the compositor, it seems like the two should be independent and calculated based on how many frames we actually composite/render rather than how many vsyncs have occurred. Is that right? What does Chrome / Safari do?
Comment on attachment 8609176 [details] [diff] [review]
Introduce frame number

Review of attachment 8609176 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/layers/ipc/CompositorParent.cpp
@@ +366,1 @@
>    ComposeToTarget(nullptr);

Instead of setting it at the software scheduler compositor, please move this to ComposeToTarget. If we have a force composite, the frame number should still increment.
(Assignee)

Comment 4

3 years ago
(In reply to Mason Chang [:mchang] from comment #2)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #0)
> > In Frame Timing API, a number needs in each
> > Performance[Render|Composite]Timing. 
> > See the spec[1] for more detail.
> > 
> > To number the same value in the same frame VsyncSource should handle the
> > variable.
> > 
> > [1]
> > http://w3c.github.io/frame-timing/#widl-PerformanceRenderTiming-
> > sourceFrameNumber
> 
> I'm not very familiar with the spec, but the patch as is will give each
> vsync frame number, not necessarily what we composited / painted. For
> example, if a paint takes longer than 16 ms, we coalesce the vsync messages
> so you can skip frame numbers sent from the vsync source. Same with the
> compositor. 
> 
> Does the spec say that you want the timing for each actual composite/paint
> and that they can diverge? Since there are two timing information fields in
> that spec, one for the rendering and one for the compositor, it seems like
> the two should be independent and calculated based on how many frames we
> actually composite/render rather than how many vsyncs have occurred. Is that
> right?

Yes, you are right. FPS on each threads can be calculated without the frame number.
But an aim of the frame number is to evaluate the smoothness of script-based animation.

From the document of the Frame Timing usage [1]:
How many draws there were per commit. For renderer thread-driven animation, (essentially JavaScript-based animation) you’ll want to a 1:1 relationship here, because that means that every frame committed by the renderer thread was drawn by the compositor thread

[1] https://github.com/w3c/frame-timing/wiki/Explainer
Comment on attachment 8609176 [details] [diff] [review]
Introduce frame number

Review of attachment 8609176 [details] [diff] [review]:
-----------------------------------------------------------------

If the API is like the example at [1], you probably also need to add an API in the VsyncSource to reset the frame numbers. 

[1] https://github.com/w3c/frame-timing/wiki/Explainer

::: layout/base/nsRefreshDriver.cpp
@@ +338,5 @@
>          nsCOMPtr<nsIRunnable> vsyncEvent =
> +             NS_NewRunnableMethodWithArgs<TimeStamp, uint32_t>(this,
> +                                                               &RefreshDriverVsyncObserver::TickRefreshDriver,
> +                                                               aVsyncTimestamp,
> +                                                               aFrameNumber);

Also compress the frame numbers like we do with mRecentVsync.

@@ +363,5 @@
>  
>        if (XRE_IsParentProcess()) {
>          MonitorAutoLock lock(mRefreshTickLock);
>          aVsyncTimestamp = mRecentVsync;
>          mProcessedVsync = true;

re-read the frame number here.
Attachment #8609176 - Flags: feedback?(mchang) → feedback+
(In reply to Hiroyuki Ikezoe (:hiro) from comment #4)
> (In reply to Mason Chang [:mchang] from comment #2)
> > (In reply to Hiroyuki Ikezoe (:hiro) from comment #0)
> > > In Frame Timing API, a number needs in each
> > > Performance[Render|Composite]Timing. 
> > > See the spec[1] for more detail.
> > > 
> > > To number the same value in the same frame VsyncSource should handle the
> > > variable.
> > > 
> > > [1]
> > > http://w3c.github.io/frame-timing/#widl-PerformanceRenderTiming-
> > > sourceFrameNumber
> > 
> > I'm not very familiar with the spec, but the patch as is will give each
> > vsync frame number, not necessarily what we composited / painted. For
> > example, if a paint takes longer than 16 ms, we coalesce the vsync messages
> > so you can skip frame numbers sent from the vsync source. Same with the
> > compositor. 
> > 
> > Does the spec say that you want the timing for each actual composite/paint
> > and that they can diverge? Since there are two timing information fields in
> > that spec, one for the rendering and one for the compositor, it seems like
> > the two should be independent and calculated based on how many frames we
> > actually composite/render rather than how many vsyncs have occurred. Is that
> > right?
> 
> Yes, you are right. FPS on each threads can be calculated without the frame
> number.
> But an aim of the frame number is to evaluate the smoothness of script-based
> animation.
> 
> From the document of the Frame Timing usage [1]:
> How many draws there were per commit. For renderer thread-driven animation,
> (essentially JavaScript-based animation) you’ll want to a 1:1 relationship
> here, because that means that every frame committed by the renderer thread
> was drawn by the compositor thread
> 
> [1] https://github.com/w3c/frame-timing/wiki/Explainer


Thanks for that github link, it explains a lot! From the example, it looks like there should be a window.clearSmoothnessTimings(). Is that also part of the spec, or just used as part of the example?
(Assignee)

Comment 7

3 years ago
Created attachment 8612703 [details] [diff] [review]
Introduce frame number v2

:mchang, thank you for your feedback. I updated the patch.

Changes from the previous patch

* compress the frame number as well as time stamp
* add new member variable in both CompositorSoftwareTimerScheduler and RefreshDriverTimer to increase frame number in case of non-vsync driver
 * Without vsync these frame numbers on each threads does not match in each frame. I will figure out the mismatch in another bug if necessary

https://treeherder.mozilla.org/#/jobs?repo=try&revision=32a9b895bf78
Attachment #8609176 - Attachment is obsolete: true
Attachment #8612703 - Flags: review?(mchang)
(In reply to Hiroyuki Ikezoe (:hiro) from comment #7)
> Created attachment 8612703 [details] [diff] [review]
> Introduce frame number v2
> 
> :mchang, thank you for your feedback. I updated the patch.
> 
> Changes from the previous patch
> 
> * compress the frame number as well as time stamp
> * add new member variable in both CompositorSoftwareTimerScheduler and
> RefreshDriverTimer to increase frame number in case of non-vsync driver
>  * Without vsync these frame numbers on each threads does not match in each
> frame. I will figure out the mismatch in another bug if necessary
> 
> https://treeherder.mozilla.org/#/jobs?repo=try&revision=32a9b895bf78

Can you please answer the question from comment 6? That would help determine if we have to figure out the mismatch or not. Thanks!
Flags: needinfo?(hiikezoe)
(Assignee)

Comment 9

3 years ago
(In reply to Mason Chang [:mchang] from comment #6)
drawn by the compositor thread
> > [1] https://github.com/w3c/frame-timing/wiki/Explainer
> 
> 
> Thanks for that github link, it explains a lot! From the example, it looks
> like there should be a window.clearSmoothnessTimings(). Is that also part of
> the spec, or just used as part of the example?

I am sorry for not answering the question.

clearSmoothnessTimings has been renamed to clearFrameTimings(). It clears the buffer for Frame Timing APIs.
Flags: needinfo?(hiikezoe)
Comment on attachment 8612703 [details] [diff] [review]
Introduce frame number v2

Review of attachment 8612703 [details] [diff] [review]:
-----------------------------------------------------------------

Looks mostly good, but you still have to deal with the case of a force composite [1]. I think it'd be better to just always increment a frame number in CompositorParent::CompositeToTarget[2] rather than the schedules. 

Does clearFrameTimings() also reset the frame numbers? Can you check what Safari/Chrome do? Do the frame numbers reset after a call to clearFrameTimings()? Because if we have ForceComposeToTarget, it will be rather difficult to keep the frame numbers in sync for anything more than a few seconds at startup as there will be divergence very quickly. 

I wonder if it's actually better to use the LayerTransactionId as the frame id here [3]. The RefreshDriver and Compositor are already throttled together based on the layer transaction id and that will keep track of paints. This gives you the 1:1 mapping between the compositor / rendering thread.

I also think you can have more compositor events than renderer events after reading the spec a bit more. The compositor event.sourceFrameNumber [4] just must return the last known source frame number for this event, which I actually think means the last known render event. Is this the case? For example, it means two compositor events can both have the same source frame number if the renderer thread was too busy?

With the current patch, let's say the renderer thread took 2 frames (32 ms) and has a vsync frame id of 10. The compositor will composite two frames, id 10 and 11. The refresh driver will render 1 frame with id 10 since it takes 32 ms. In this case, should the two compositor frames actually have the same frame id of 10 to correlate them with the refresh driver? This will be possible if we use the LayerTransactionId but not if we add a frame number to the vsync source. From the spec, it looks like this number is used explicitly to correlate the RenderTiming. From section 4.1 - "For example, the user agent may report many PerformanceCompositeTiming events corresponding to a single PerformanceRenderTiming event due to a CSS animation, composite thread scrolling, or similar activities." - I think this is the actual case and so we don't want to increment the frame number if a composite occurs but not a render frame.

Can we try reworking this patch to use the LayerTransactionId instead? It will hopefully be a lot simpler! Sorry for all the rewrites :(, took me a while to understand the spec. If you could also please see what Chrome/Safari/IE do, I'd appreciate it!


[1] https://dxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/CompositorParent.cpp#259
[2] https://dxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/CompositorParent.cpp#1084
[3] https://dxr.mozilla.org/mozilla-central/source/gfx/layers/ipc/CompositorParent.cpp?from=CompositorParent.cpp&case=true#1216
[4] http://w3c.github.io/frame-timing/#attributes-2
Attachment #8612703 - Flags: review?(mchang)
(Assignee)

Comment 11

3 years ago
:mchang, thank you for your reviewing in detail. Your review comments help me to understand the codes around Vsync/Refresh drivers.

First of all, I should have mentioned about the transactionId.
Actually I tried to use it first, but it could not be used as frame number since the transactionId is not advanced in most cases as I expected. For example, if a transaction id is 123, then the transaction id is still 123 in next frame (i.e. in next nsRefreshDriver::Tick()) even if the main thread is not busy. Moreover, as far as I can see, the transaction id which can be obtained in compositor thread corresponds the id owned by the refresh driver of top level window (i.e. browser.xul) not html document. For these reasons I decided to add a new variable as frame number to be counted itself in vsync driver.

(In reply to Mason Chang [:mchang] from comment #10)
> Looks mostly good, but you still have to deal with the case of a force
> composite [1].

Yes. force composition is annoying me. Now I am thinking it's OK that the number stays in case of force composition.

> I think it'd be better to just always increment a frame
> number in CompositorParent::CompositeToTarget[2] rather than the schedules. 

Increment of the number in CompositeToTarget will cause skew between the numbers in main and compositor threads, will not? A sync message between threads can adjust the numbers in both threads but I think the cost is not negligible. Am I missing something?

> Does clearFrameTimings() also reset the frame numbers? Can you check what
> Safari/Chrome do? Do the frame numbers reset after a call to
> clearFrameTimings()?

No. The frame number is just monotonically increased. Chrome(blink) does not reset it. Webkit does not seem to start to implement the Frame Timing APIs, AFAIK.

> Because if we have ForceComposeToTarget, it will be
> rather difficult to keep the frame numbers in sync for anything more than a
> few seconds at startup as there will be divergence very quickly. 
> 
> I wonder if it's actually better to use the LayerTransactionId as the frame
> id here [3]. The RefreshDriver and Compositor are already throttled together
> based on the layer transaction id and that will keep track of paints. This
> gives you the 1:1 mapping between the compositor / rendering thread.
> 
> I also think you can have more compositor events than renderer events after
> reading the spec a bit more. The compositor event.sourceFrameNumber [4] just
> must return the last known source frame number for this event, which I
> actually think means the last known render event. Is this the case? For
> example, it means two compositor events can both have the same source frame
> number if the renderer thread was too busy?

In my understandings of the Frame Timing spec, it's not well-documented whether the two compositor events have the same frame number or different numbers in such case. I believe it depends on user agent.

In current implementation of Frame Timing API I am working on, the two compositor events will have different frame number. And (a) frame number(s) in render events will be dropped. 

For example:

frame number      1         2         3
render       |RRRRRRRRRRRRRR-----|RRRRRR---|
composite    |-----C---|-----C---|----C----|

In above case, there are two render events:
{ sourceFrameNumber: 1, startTime: xx, .. }
{ sourceFrameNumber: 3, startTime: xx, .. }
and three composite events:
{ sourceFrameNumber: 1, startTime: xx, .. }
{ sourceFrameNumber: 2, startTime: xx, .. }
{ sourceFrameNumber: 3, startTime: xx, .. }


> With the current patch, let's say the renderer thread took 2 frames (32 ms)
> and has a vsync frame id of 10. The compositor will composite two frames, id
> 10 and 11. The refresh driver will render 1 frame with id 10 since it takes
> 32 ms. In this case, should the two compositor frames actually have the same
> frame id of 10 to correlate them with the refresh driver? This will be
> possible if we use the LayerTransactionId but not if we add a frame number
> to the vsync source. From the spec, it looks like this number is used
> explicitly to correlate the RenderTiming. From section 4.1 - "For example,
> the user agent may report many PerformanceCompositeTiming events
> corresponding to a single PerformanceRenderTiming event due to a CSS
> animation, composite thread scrolling, or similar activities." - I think
> this is the actual case and so we don't want to increment the frame number
> if a composite occurs but not a render frame.

Ooops. I described this case above.

> Can we try reworking this patch to use the LayerTransactionId instead? It
> will hopefully be a lot simpler! Sorry for all the rewrites :(, took me a
> while to understand the spec. 

Don't mention it. I am happy that the codes will be simpler and more readable if I rewrite the codes.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #11)
> :mchang, thank you for your reviewing in detail. Your review comments help
> me to understand the codes around Vsync/Refresh drivers.
> 
> First of all, I should have mentioned about the transactionId.
> Actually I tried to use it first, but it could not be used as frame number
> since the transactionId is not advanced in most cases as I expected. For
> example, if a transaction id is 123, then the transaction id is still 123 in
> next frame (i.e. in next nsRefreshDriver::Tick()) even if the main thread is
> not busy. Moreover, as far as I can see, the transaction id which can be
> obtained in compositor thread corresponds the id owned by the refresh driver
> of top level window (i.e. browser.xul) not html document. For these reasons
> I decided to add a new variable as frame number to be counted itself in
> vsync driver.

Hmm that is interesting. The refresh driver and compositor can tick independently, but the Compositor should be able to get 1 frame ahead of the refresh driver, which might be the case you're seeing here. If the refresh driver is taking too long, the Compositor gets throttled by the refresh driver but can still be 1 layer transaction ahead - https://dxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.cpp?from=nsRefreshDriver.cpp&case=true#1935. Can you please double check if this is happening?

> 
> (In reply to Mason Chang [:mchang] from comment #10)
> > Looks mostly good, but you still have to deal with the case of a force
> > composite [1].
> 
> Yes. force composition is annoying me. Now I am thinking it's OK that the
> number stays in case of force composition.
> 
> > I think it'd be better to just always increment a frame
> > number in CompositorParent::CompositeToTarget[2] rather than the schedules. 
> 
> Increment of the number in CompositeToTarget will cause skew between the
> numbers in main and compositor threads, will not? A sync message between
> threads can adjust the numbers in both threads but I think the cost is not
> negligible. Am I missing something?

Hmm ok, I am OK with not incrementing the frame number during Force composites then.

> > Does clearFrameTimings() also reset the frame numbers? Can you check what
> > Safari/Chrome do? Do the frame numbers reset after a call to
> > clearFrameTimings()?
> 
> No. The frame number is just monotonically increased. Chrome(blink) does not
> reset it. Webkit does not seem to start to implement the Frame Timing APIs,
> AFAIK.

Ok, thanks for finding this. 

> 
> In my understandings of the Frame Timing spec, it's not well-documented
> whether the two compositor events have the same frame number or different
> numbers in such case. I believe it depends on user agent.
> 
> In current implementation of Frame Timing API I am working on, the two
> compositor events will have different frame number. And (a) frame number(s)
> in render events will be dropped. 
> 
> For example:
> 
> frame number      1         2         3
> render       |RRRRRRRRRRRRRR-----|RRRRRR---|
> composite    |-----C---|-----C---|----C----|
> 
> In above case, there are two render events:
> { sourceFrameNumber: 1, startTime: xx, .. }
> { sourceFrameNumber: 3, startTime: xx, .. }
> and three composite events:
> { sourceFrameNumber: 1, startTime: xx, .. }
> { sourceFrameNumber: 2, startTime: xx, .. }
> { sourceFrameNumber: 3, startTime: xx, .. }

OK, so if this is the expected behavior then yes, doing it at the vsync level is correct. Just to make sure we're web compliant and not coming up with something else, can we verify that this is the case with Chrome? You should be able to test this by making a requestAnimationFrame in a test case take a very long time to artificially hold the render thread.
Flags: needinfo?(hiikezoe)
(Assignee)

Comment 13

3 years ago
Created attachment 8615103 [details]
A test html to get frame timing entries periodically

(In reply to Mason Chang [:mchang] from comment #12)
> Hmm that is interesting. The refresh driver and compositor can tick
> independently, but the Compositor should be able to get 1 frame ahead of the
> refresh driver, which might be the case you're seeing here. If the refresh
> driver is taking too long, the Compositor gets throttled by the refresh
> driver but can still be 1 layer transaction ahead -
> https://dxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.
> cpp?from=nsRefreshDriver.cpp&case=true#1935. Can you please double check if
> this is happening?

No.

Attaching HTML file has an animation and dumps frame timing entries periodically.

An output using transaction id as frame number is:

render timing:
[ startTime,	frameNumber ]
[ 12088.716,	29 ]
[ 12104.906,	29 ]
[ 12122.059,	29 ]
[ 12138.197,	29 ]
[ 12155.289,	29 ]
[ 12171.453,	29 ]
[ 12188.570,	29 ]
[ 12205.637,	29 ]
[ 12221.770,	29 ]
[ 12238.924,	29 ]
[ 12255.070,	29 ]
[ 12272.203,	29 ]
[ 12288.348,	29 ]
[ 12305.492,	29 ]
<snip>

composite timing:
[ startTime,	frameNumber ]
[ 12104.975,	56 ]
[ 12122.124,	56 ]
[ 12138.231,	56 ]
[ 12155.348,	56 ]
[ 12171.481,	56 ]
[ 12188.596,	56 ]
[ 12205.717,	56 ]
[ 12221.862,	56 ]
[ 12238.983,	56 ]
[ 12255.129,	56 ]
[ 12272.260,	56 ]
[ 12288.404,	56 ]
[ 12305.541,	56 ]
<snip>

After starting the animation frame number does not change basically, it changes when mouse cursor is moved on the document.
The reason of difference the frame numbers between render timing and composite timing is that the number in render timing entries is the transaction id of test.html, but the composite one is the id of browser.xul.

For comparison, an output from the same HTML using frame number which is counted by vsync source is:

render:
[ startTime,	frameNumber ]
[ 6119.753,	617 ]
[ 6135.896,	618 ]
[ 6153.010,	619 ]
[ 6170.121,	620 ]
[ 6186.361,	621 ]
[ 6203.452,	622 ]
[ 6219.557,	623 ]
[ 6236.655,	624 ]
[ 6252.760,	625 ]
[ 6269.856,	626 ]
[ 6285.953,	627 ]
[ 6303.051,	628 ]
[ 6320.121,	629 ]
[ 6336.251,	630 ]
<snip>

composite:
[ startTime,	frameNumber ]
[ 6135.986,	618 ]
[ 6153.040,	619 ]
[ 6170.437,	620 ]
[ 6186.394,	621 ]
[ 6203.491,	622 ]
[ 6219.592,	623 ]
[ 6236.688,	624 ]
[ 6252.790,	625 ]
[ 6269.884,	626 ]
[ 6285.982,	627 ]
[ 6303.086,	628 ]
[ 6320.187,	629 ]
<snip>
Flags: needinfo?(hiikezoe)
(Assignee)

Comment 14

3 years ago
(In reply to Mason Chang [:mchang] from comment #12)

> OK, so if this is the expected behavior then yes, doing it at the vsync
> level is correct. Just to make sure we're web compliant and not coming up
> with something else, can we verify that this is the case with Chrome?

Yes, I will check the behavior on Chrome once the Frame Timing APIs works on Chrome. I don't understand what happens in the case from source codes of Chrome.
(In reply to Hiroyuki Ikezoe (:hiro) from comment #13)
> Created attachment 8615103 [details]
> A test html to get frame timing entries periodically
> 
> (In reply to Mason Chang [:mchang] from comment #12)
> > Hmm that is interesting. The refresh driver and compositor can tick
> > independently, but the Compositor should be able to get 1 frame ahead of the
> > refresh driver, which might be the case you're seeing here. If the refresh
> > driver is taking too long, the Compositor gets throttled by the refresh
> > driver but can still be 1 layer transaction ahead -
> > https://dxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.
> > cpp?from=nsRefreshDriver.cpp&case=true#1935. Can you please double check if
> > this is happening?
> 
> No.
> 
> Attaching HTML file has an animation and dumps frame timing entries
> periodically.
> 

Thanks for this, that helps explains a lot. OK, as long as we're consistent with Chrome 
then we can do this in the Vsync Source. Sorry for so many hoops!

The current test I expect actually shouldn't do anything on the render frame since it looks like it should be a CSS animation. Do you get the same results with a requestAnimationFrame animation?
(Assignee)

Comment 16

3 years ago
(In reply to Mason Chang [:mchang] from comment #15)
> (In reply to Hiroyuki Ikezoe (:hiro) from comment #13)
> > Created attachment 8615103 [details]
> > A test html to get frame timing entries periodically
> > 
> > (In reply to Mason Chang [:mchang] from comment #12)
> > > Hmm that is interesting. The refresh driver and compositor can tick
> > > independently, but the Compositor should be able to get 1 frame ahead of the
> > > refresh driver, which might be the case you're seeing here. If the refresh
> > > driver is taking too long, the Compositor gets throttled by the refresh
> > > driver but can still be 1 layer transaction ahead -
> > > https://dxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.
> > > cpp?from=nsRefreshDriver.cpp&case=true#1935. Can you please double check if
> > > this is happening?
> > 
> > No.
> > 
> > Attaching HTML file has an animation and dumps frame timing entries
> > periodically.
> > 
> 
> Thanks for this, that helps explains a lot. OK, as long as we're consistent
> with Chrome 
> then we can do this in the Vsync Source. Sorry for so many hoops!
> 
> The current test I expect actually shouldn't do anything on the render frame
> since it looks like it should be a CSS animation. Do you get the same
> results with a requestAnimationFrame animation?

Ah, right. The current implementation is wrong. I will revise it. Thanks!
(Assignee)

Comment 17

3 years ago
The behavior of frame numbers on Chrome is similar to the transaction id on Firefox. So I've decided to use the transaction id as frame number on Firefox too. But I am going to leave this bug open for now.

Mason, thanks for lots of advices!
(Assignee)

Comment 18

3 years ago
Removing dependency.

I will leave this bug open since this bug will be needed in the future.
No longer blocks: 1158032
Keywords: correctness
You need to log in before you can comment on or make changes to this bug.