[webkit-qt] Performance (regression?) of window.requestAnimationFrame

Noam Rosenthal noam at webkit.org
Wed Mar 13 10:26:26 PDT 2013


Hi Milian
Could https://bugs.webkit.org/show_bug.cgi?id=112095 be what you're talking
about?


On Wed, Mar 13, 2013 at 6:24 PM, Milian Wolff <milian.wolff at kdab.com> wrote:

> Hey all!
>
> As you might have seen on IRC recently, I have hit a big issue in QtWebKit
> when using window.requestAnimationFrame (rAF): Apparently, it triggers a
> full
> repaint of the web view which can lead to abysmal performance.
>
> To reproduce, see this test code: http://paste.kde.org/~mwolff/695234/
>
> If I open it in Chromium, I cannot notice any performance impact, nor do I
> see
> a load spike in ksysguard/top or similar.
>
> Now, doing the same in MiniBrowser I see that X starts to use ~20% of CPU
> and
> MiniBrowser 10%. My system becomes noticeably slugglish (I use KWin as
> window
> compositor with GPU accelleration enabled). On an embedded device we see a
> demo app using >50% CPU constantly as soon as it uses rAF.
>
> Also looking at the timeline tab in the developer console yields these
> interesting results:
>
> In MiniBrowser: http://imagebin.org/249849
> In Chromium: http://imagebin.org/249848
>
> Looking at a cachegrind of MiniBrowser with the above file I see tons of
> calls
> to QSGRenderer::draw(QSGMaterialShader).
>
> In the code I found this:
>
> void CoordinatedLayerTreeHostProxy::requestAnimationFrame()
> {
>     dispatchUpdate(bind(&CoordinatedGraphicsScene::requestAnimationFrame,
> m_scene.get()));
>     updateViewport(); // <-- does this trigger a repaint of everything?
> }
>
> Furthermore I experimented with the TweenMax [1] JS library and reproduced
> the
> performance issues there. Interestingly enough, disabling its support for
> rAF
> via TweenMax.ticker.useRAF(false); made the animations much smoother and
> greatly reduced the System/CPU load. This is in so far interesting, as
> TweenMax uses a window.setTimeout based fallback in such cases. Afaik rAF
> was
> initially introduced to *improve* the performance of animations compared to
> the timer approach, no?
>
> All this combined brings me to the conclusion that QtWebKit as-is has a big
> performance issue with rAF. On IRC it was said that kbalazs is looking into
> this but I could not get hold of him. Is this true? What's the status? Is
> there anything I could do?
>
> On IRC there was also the mention of "the operationqueue patch" and that it
> may have introduced a regression. Which patch exactly is this so I could
> try
> to revert to a time before it and see whether it actually is the reason?
>
> Thanks!
>
> [1]: http://www.greensock.com/gsap-js/
> --
> Milian Wolff | milian.wolff at kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel. Germany +49-30-521325470, Sweden (HQ) +46-563-540090
> KDAB - Qt Experts - Platform-independent software solutions
>
> _______________________________________________
> webkit-qt mailing list
> webkit-qt at lists.webkit.org
> https://lists.webkit.org/mailman/listinfo/webkit-qt
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20130313/ecf5e568/attachment.html>


More information about the webkit-qt mailing list