Bug 117703

Summary: [WK2][GTK] 100% CPU usage rendering a page with animations
Product: WebKit Reporter: Sergio Villar Senin <svillar>
Component: WebKitGTKAssignee: Sergio Villar Senin <svillar>
Status: RESOLVED FIXED    
Severity: Major CC: alex, andersca, ap, cgarcia, gustavo, mrobinson, ossy, rego, sergio, svillar, thorton
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
URL: http://hugogiraudel.com/2013/04/04/css-grid-layout/
Attachments:
Description Flags
Patch none

Description Sergio Villar Senin 2013-06-17 09:23:46 PDT
Try to load the above page using the WebKit2 Gtk port (Minibrowser is OK). After the load finishes scrolling becomes impossible, it's even not possible to click on links. From what I've seen trying to get WebProcess backtraces while this happens, I think the culprit is some animation at the very end of the page.
Comment 1 Sergio Villar Senin 2013-06-17 09:29:17 PDT
Not sure if very useful, but it looks like the code is constantly doing this:

(gdb) bt
#0  0x00007fbde8989b9a in WTF::HashTableConstIterator<WTF::RefPtr<WebCore::Widget>, WTF::RefPtr<WebCore::Widget>, WTF::IdentityExtractor, WTF::PtrHash<WTF::RefPtr<WebCore::Widget> >, WTF::HashTraits<WTF::RefPtr<WebCore::Widget> >, WTF::HashTraits<WTF::RefPtr<WebCore::Widget> > >::get () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#1  0x00007fbde8988d32 in WTF::HashTableConstIteratorAdapter<WTF::HashTable<WTF::RefPtr<WebCore::Widget>, WTF::RefPtr<WebCore::Widget>, WTF::IdentityExtractor, WTF::PtrHash<WTF::RefPtr<WebCore::Widget> >, WTF::HashTraits<WTF::RefPtr<WebCore::Widget> >, WTF::HashTraits<WTF::RefPtr<WebCore::Widget> > >, WTF::RefPtr<WebCore::Widget> >::get () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#2  0x00007fbde8987d8c in WTF::HashTableConstIteratorAdapter<WTF::HashTable<WTF::RefPtr<WebCore::Widget>, WTF::RefPtr<WebCore::Widget>, WTF::IdentityExtractor, WTF::PtrHash<WTF::RefPtr<WebCore::Widget> >, WTF::HashTraits<WTF::RefPtr<WebCore::Widget> >, WTF::HashTraits<WTF::RefPtr<WebCore::Widget> > >, WTF::RefPtr<WebCore::Widget> >::operator* () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#3  0x00007fbde91320c8 in collectFrameViewChildren () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#4  0x00007fbde913bcca in WebCore::FrameView::updateLayoutAndStyleIfNeededRecursive () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#5  0x00007fbde88490ce in WebKit::WebPage::layoutIfNeeded () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#6  0x00007fbde88758d4 in WebKit::LayerTreeHostGtk::flushAndRenderLayers () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#7  0x00007fbde887554c in WebKit::LayerTreeHostGtk::layerFlushTimerFired () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#8  0x00007fbde88754ec in WebKit::LayerTreeHostGtk::layerFlushTimerFiredCallback () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#9  0x00007fbde503bb5e in g_timeout_dispatch (source=0x1bf20c0, callback=0x7fbde88754d4 <WebKit::LayerTreeHostGtk::layerFlushTimerFiredCallback(WebKit::LayerTreeHostGtk*)>, user_data=0x17f5fe0) at gmain.c:4417
#10 0x00007fbde5039e01 in g_main_dispatch (context=0x112f960) at gmain.c:3058
#11 0x00007fbde503ab66 in g_main_context_dispatch (context=0x112f960) at gmain.c:3634
#12 0x00007fbde503ad56 in g_main_context_iterate (context=0x112f960, block=1, dispatch=1, self=0x117b500) at gmain.c:3705
#13 0x00007fbde503b186 in g_main_loop_run (loop=0x1167ea0) at gmain.c:3899
#14 0x00007fbde9ed149a in WebCore::RunLoop::run () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#15 0x00007fbde8782a8c in WebProcessMainGtk () from /opt/checkout/WebKit/WebKitBuild/Debug/.libs/libwebkit2gtk-3.0.so.25
#16 0x00000000004009fc in main ()
Comment 2 Martin Robinson 2013-06-17 10:00:35 PDT
Hrm. Do you see the same issue with the Qt or EFL port? From the stack, what's happening is that it's doing a relayout.  The amount that this happens should be limited to the page framerate.
Comment 3 Sergio Villar Senin 2013-06-17 10:33:30 PDT
(In reply to comment #2)
> Hrm. Do you see the same issue with the Qt or EFL port? From the stack, what's happening is that it's doing a relayout.  The amount that this happens should be limited to the page framerate.

My Qt build does not show that behavior, although it's a bit older, I'll try with a more recent build.

Anyway, maybe the problem is precisely that it's constantly relayouting when it shouldn't?
Comment 4 Sergio Villar Senin 2013-06-17 12:25:25 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > Hrm. Do you see the same issue with the Qt or EFL port? From the stack, what's happening is that it's doing a relayout.  The amount that this happens should be limited to the page framerate.
> 
> My Qt build does not show that behavior, although it's a bit older, I'll try with a more recent build.

Qt port behaves correctly, as the summary suggests this is a gtk only issue
Comment 5 Manuel Rego Casasnovas 2013-06-18 02:01:07 PDT
(In reply to comment #0)
> Try to load the above page using the WebKit2 Gtk port (Minibrowser is OK). After the load finishes scrolling becomes impossible, it's even not possible to click on links. From what I've seen trying to get WebProcess backtraces while this happens, I think the culprit is some animation at the very end of the page.

I can confirm this behavior it's happening the same to me, even WebView becomes black after a while.
Comment 6 Sergio Villar Senin 2013-06-27 07:39:28 PDT
Created attachment 205606 [details]
Patch
Comment 7 Sergio Villar Senin 2013-06-28 07:50:09 PDT
Comment on attachment 205606 [details]
Patch

Clearing flags on attachment: 205606

Committed r152165: <http://trac.webkit.org/changeset/152165>
Comment 8 Sergio Villar Senin 2013-06-28 07:50:24 PDT
All reviewed patches have been landed.  Closing bug.