<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - Use requestAnimationFrame() to schedule new frames on the performance test Animation/balls.html"
href="https://bugs.webkit.org/show_bug.cgi?id=160505">160505</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>Use requestAnimationFrame() to schedule new frames on the performance test Animation/balls.html
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>OS</th>
<td>Unspecified
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Tools / Tests
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>clopez@igalia.com
</td>
</tr>
<tr>
<th>CC</th>
<td>bugs-noreply@webkitgtk.org, cgarcia@igalia.com, jdapena@igalia.com, lforschler@apple.com, rniwa@webkit.org, simon.fraser@apple.com, tomz@codeaurora.org, tonikitoo@webkit.org
</td>
</tr></table>
<p>
<div>
<pre>On the GTK+ port we recently switched by default to use the new threaded compositor. This has improved overall performance.
However, the performance test Animation/balls.html shows a performance drop of 22% <a href="https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22gtk%22%2C%22Animation%2Fballs%3AFrameRate%22%5D%5D&days=100">https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22gtk%22%2C%22Animation%2Fballs%3AFrameRate%22%5D%5D&days=100</a>
And if you run the test manually, it is completely evident that rather than a performance drop there is huge performance boost.
- Before (no threaded compositor): <a href="https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/webkitgtk-simplecompositor_balls-old-settinterval.mp4">https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/webkitgtk-simplecompositor_balls-old-settinterval.mp4</a>
- Now (with threaded compositor): <a href="https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/webkitgtk-threadedcompositor_balls-old-settinterval.mp4">https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/webkitgtk-threadedcompositor_balls-old-settinterval.mp4</a>
So, as you can see the balls move better and the FPS rate seems improved with the new threaded compositor.
However the FPS values measured by the test don't match what it is being painted on the screen.
After a detailed analysis, I have concluded that the issue is on the test itself.
The test is measuring much more FPS than it is actually drawing, because it uses "setInterval(animate,1)" to schedule new frames.
And the issues with this are:
- Issue #1: There is no guarantee that a given call to animate() would have finished when the next one arrives. So this is calling animate() each 1 millisecond without caring about if the previous call to animate() has finished.
- Issue #2: There is no guarantee that after animate() has finished updating the ball positions this new positions will be draw at all on the screen.
I have tried also to use setTimeout(animate,0) and this fixes the first issue but not the second. It is very possible that the test thinks that it is drawing a FPS when in reality is just completing the animate() callback updating the ball positions, but nothing on the screen has been still drawn because the internal repaint timer has not been fired.
So, the best solution (IMHO) is to rely on requestAnimationFrame() that guarantees that any call to animate() will be drawn.
I have uploaded the 3 versions of the benchmark here, in case you can check if there is any difference on the FPS values reported with your browser:
- <a href="https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/Animation/">https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/Animation/</a>
I also have done a detailed analysis of the measured performance and real performance with some videos:
- <a href="https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/analisis.html">https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/analisis.html</a>
As you can see the version of the test that measures a FPS value nearest to the one later obtained by inspecting the video frames is the one using requestAnimationFrame() for all cases.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>