If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Create a benchmark to measure refresh driver alignment to vsync and detect regressions

RESOLVED WORKSFORME

Status

()

Core
Graphics
RESOLVED WORKSFORME
3 years ago
8 months ago

People

(Reporter: mchang, Assigned: mchang)

Tracking

Trunk
ARM
Gonk (Firefox OS)
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(7 attachments)

(Assignee)

Description

3 years ago
Created attachment 8515121 [details]
Vsync Aligned Refresh Driver Profile

+++ This bug was initially created as a clone of Bug #1077651 +++

Come up and measure the performance of the vsync aligned refresh driver. Currently the code lives in https://github.com/JerryShih/gecko-dev/tree/silk-simple-framework-refresh-driver for b2g.

I have a small requestAnimationFrame driven app here - https://github.com/changm/OMTA-Examples. 

I have attached a cleopatra profile of running the requestAnimationFrame example on a flame with both a vsync aligned compositor and refresh driver. Overall, I don't see a large improvement yet but we can still tweak and see why and what's going on.
(Assignee)

Comment 1

3 years ago
Created attachment 8515123 [details]
Profile w/ no longer forced refreshes

In the original profile, I saw that we were sometimes doubling the amount of ticks in a vsync interval due to the compositor notifying that a transaction flushed. This profile is a tweak where we only refresh on vsync intervals - http://dxr.mozilla.org/mozilla-central/source/layout/base/nsRefreshDriver.cpp?from=nsRefreshDriver.cpp&case=true#1480
(Assignee)

Comment 2

3 years ago
Created attachment 8515124 [details]
Profile of running animation in master

Just leaving this here as a reference point
(Assignee)

Comment 3

3 years ago
From https://bugzilla.mozilla.org/show_bug.cgi?id=1080869#c8, running the page on a flame device is very janky and we miss most frames because we can't keep up with the animation on a flame device. FPS hovers around 15-18fps. Will test again on desktop at a later time.
(Assignee)

Comment 4

3 years ago
Created attachment 8515240 [details]
Profile w/ Animation to use translateY

Changed the animation to use translateY versus setting margin-top. Refresh driver times are down. Visually, I can see that it is a little smoother with some large janks every couple of seconds. I sometimes see 5ms latency between getting a vsync notification and the main thread executing the posted task.
(Assignee)

Comment 5

3 years ago
Created attachment 8515365 [details]
Refresh Driver Position Uniformity

I modified the requestAnimationFrame to collect frame position data over 1 minute of animations. It then reports the average frame differential as well as the standard deviation. In all cases, the vsync aligned refresh driver produces more uniform frame positions. All tests done on a flame.
 
I also collected desktop chrome / desktop firefox as reference points. Desktop chrome can produce a standard deviation < 0.3 and is the smoothest, even with visual inspection. Desktop firefox still janks once in a while as well as the flame. 

As another data point, I hard coded requestAnimationFrames to be exactly 16.66666 ms apart. I still see janks and somewhat higher std deviation, which is actually confusing. From the profiles, we are able to keep up every frame. Will investigate some more.
(Assignee)

Comment 6

3 years ago
From comment 5, the ideal would be an average of 5.000000 pixels per frame with a standard deviation of 0.
Depends on: 1092978
(Assignee)

Comment 7

3 years ago
Created attachment 8516248 [details]
Refresh Driver Uniformity Timings

I measured the software compositor, hardware composer vsync event, and the precise refresh driver timer while running the requestAnimationFrame test here - https://github.com/changm/OMTA-Examples/tree/master/raf. Test setup is explained here - https://bugzilla.mozilla.org/show_bug.cgi?id=1077651#c30

What we see compared to bug 1077651 are a couple of things. Both the compositor and hardware vsync measurements get a bit more noisy. The standard deviation for the computer jumps from ~1000 ms to ~1100 ms. The hardware composer vsync notifications noise jumps a bit more from ~15 us to ~100 us, which is still much better than the software timers. The refresh driver has some interesting characteristics. It has very noisy behavior ranging from 15 ms - 18 ms refreshes, but what's more interesting is that I sometimes see two refresh driver ticks in 1 vsync interval. For example, I'll see one at 14 ms then another at 2 ms, which brings down the average quite a bit. The refresh driver is also much noisier than the compositor. Another interesting thing is that vsync intervals were more abnormal with this test case, with an average of 10 intervals that were less than 16 ms or greater than 17 ms per 3600 frames. Overall though, vsync intervals are much much cleaner.
(Assignee)

Comment 8

3 years ago
Created attachment 8516779 [details]
240 FPS Video of RequestAnimationFrame Video

240 FPS video of two flames. The one on the left has silk. I personally can't tell a difference, but a friend said he could. Maybe someone with a better eye can see this.
Blocks: 1073549
Changing bug summary to prevent this bug from turning into a dumping ground of data with no real objective.
Summary: Refresh Driver Performance Tests and Results for Silk → Create a benchmark to measure refresh driver alignment to vsync and detect regressions
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1078160
(Assignee)

Comment 11

8 months ago
Closing old bugs.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.