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

[Milian Wolff]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.webkit.org/pipermail/webkit-qt/attachments/20130313/e6c89bbd/attachment.sig>