Closed Bug 1092245 Opened 6 years ago Closed 4 years ago

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


(Core :: Graphics, defect)

Gonk (Firefox OS)
Not set





(Reporter: mchang, Assigned: mchang)




(7 files)

+++ 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 for b2g.

I have a small requestAnimationFrame driven app here - 

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.
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 -
Just leaving this here as a reference point
From, 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.
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.
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.
From comment 5, the ideal would be an average of 5.000000 pixels per frame with a standard deviation of 0.
I measured the software compositor, hardware composer vsync event, and the precise refresh driver timer while running the requestAnimationFrame test here - Test setup is explained here -

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.
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.
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
Duplicate of this bug: 1078160
Closing old bugs.
Closed: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.