[Webkit-unassigned] [Bug 160505] New: Use requestAnimationFrame() to schedule new frames on the performance test Animation/balls.html

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=160505

            Bug ID: 160505
           Summary: Use requestAnimationFrame() to schedule new frames on
                    the performance test Animation/balls.html
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Tools / Tests
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: clopez at igalia.com
                CC: bugs-noreply at webkitgtk.org, cgarcia at igalia.com,
                    jdapena at igalia.com, lforschler at apple.com,
                    rniwa at webkit.org, simon.fraser at apple.com,
                    tomz at codeaurora.org, tonikitoo at webkit.org

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% https://perf.webkit.org/#mode=charts&chartList=%5B%5B%22gtk%22%2C%22Animation%2Fballs%3AFrameRate%22%5D%5D&days=100

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): https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/webkitgtk-simplecompositor_balls-old-settinterval.mp4
 - Now  (with threaded compositor): https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/webkitgtk-threadedcompositor_balls-old-settinterval.mp4

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:

 - https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/Animation/


I also have done a detailed analysis of the measured performance and real performance with some videos:

 - https://people.igalia.com/clopez/wkbug/animation-balls-threaded-compositor/videos/analisis.html

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160803/93999231/attachment.html>