Created attachment 181660 [details] ZIP file with test program and test page Visual Studio 2010 and Windows 7 64bit (as well as Windows XP 32bit) A page with a simple CSS animation has (see attachment) - with Qt4.8's QtWebKit: almost no CPU load (no matter which machine and windows version) - with Qt5's QtWebKit: - CPU load of 40%-60% (virtual machine with WinXP and single core emulation) - CPU load of 20%-30% (real PC with Win 7 64bit, Intel Xeon CPU X3470) If you toggle the CSS animation off or resize the window so that you will not see the animation, the CPU load drops to almost zero. I attached a test program which initially shows an html page (also included). You can also take the fancybrowser example to see the much higer CPU load. The attached html page includes a very simple CSS animation. Normally we have more sophisticated animations with pictures which can cause even higher CPU loads. On a single core machine our _real_ application is not working anymore, because the UI application is taking 100% CPU and all other processes are stuck! Apart from a much higher memory consumption, this is a stopper for us to go on with Qt5. Of course the CPU load depends on CPU and OS. If you measure the load be sure that you do NOT only use the number from the Task Manager in the Process tab. Because what you see there is the CPU load divided by the number of CPU cores, i.e. the number there is much lesser. Take a look at the Performance tab, there you can see the load for every core.
There is an inset box-shadow in your test. They are pretty slow to draw, and was not implemented in Qt 4.8 and not optimized for in Qt 5.0. There are however optimizations for it the alpha Qt 5.1.
Created attachment 199411 [details] test_animation.html Attaching the test-case for easy testing and download.
Besides using a slow painted feature, part of the problem with this page is that the 'point' elements are not accelerated composited, which means the point and therefore the shadow is repainted completely 60 times a second (or as fast as the CPU allows). If they were composited correctly, they would be painted once and only the opacity adjusted. You can use a clasic WebKit trick for force compositing which improves performance greatly. Just add: .point { -webkit-transform: translateZ(0); }
(In reply to comment #3) Thank you Allan! With your help we have now a much better performance compared to the initial solution. The hint with box-shadow did the trick. I tested now only on Windows XP single-core and will retest on Windows 7 later: If we delete box-shadow the CPU usage goes down from around 40-60% to around 8-19% If we delete box-shadow AND add '-webkit-transform: translateZ(0);' the CPU usage goes down to 10-16%. It looks like its the same in average but it does not oscillate so much... If we leave the box-shadow and add '-webkit-transform: translateZ(0);' as in your last comment, then the CPU load also drops but only down to around 25-35%. Still better than original. Maybe we will leave this for design-reasons and live with that performance. Of course, compared to Chrome/Chromium it still uses much more CPU but at least our application will not be blocked due to the CSS animations. I will now take a deeper look to what '-webkit-transform: translateZ(0);' really means :-) Thanks!
With the patch from bug 115107 the points should now automatically become composited. You can however still get an additional performance boost by manually triggering compositing on the clock (using -webkit-transform: translateZ(0) ). I believe the issues with converting values and memory consumption should already have been improved greatly in Qt 5.1 alpha1.