[Qt] Trigger forcing accelerated compositing from the UI process side.
Created attachment 122478 [details] Patch
Comment on attachment 122478 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=122478&action=review r=me with nitpicks > Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp:65 > + // Construct the proxy early to allow messages to be sent to the web process ASAP. > + if (webPageProxy->pageGroup()->preferences()->forceCompositingMode()) > + m_layerTreeHostProxy = adoptPtr(new LayerTreeHostProxy(this)); > +#endif Instead of ASAP say when messages actually need to be sent, e.g. "before page load". Put this in PLATFORM(QT), other ports with WebKit2+TextureMapper might not want this. > Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp:675 > if (m_layerTreeHost) You don't need this condition if you assert
(In reply to comment #2) > Put this in PLATFORM(QT), other ports with WebKit2+TextureMapper might not want this. The Qt platform isn't producing any specific behavior that isn't already covered by the forceCompositingMode() condition. I also like the benefit of having the texture mapper behaving as close as possible between ports to reduce the number of platform specific bugs and keep the code paths straightforward. I fixed the other issues.
(In reply to comment #3) > (In reply to comment #2) > > Put this in PLATFORM(QT), other ports with WebKit2+TextureMapper might not want this. > The Qt platform isn't producing any specific behavior that isn't already covered by the forceCompositingMode() condition. I also like the benefit of having the texture mapper behaving as close as possible between ports to reduce the number of platform specific bugs and keep the code paths straightforward. Other ports that use texture-mapper don't have a LayerTreeHostProxy at this time. So generating a LayerTreeHostProxy for them at that point would break their webkit2.
(In reply to comment #4) > Other ports that use texture-mapper don't have a LayerTreeHostProxy at this time. So generating a LayerTreeHostProxy for them at that point would break their webkit2. As talked on IRC, this wouldn't be an issue as of today in trunk, so we can ifdef it out once it becomes a problem.
Committed r105497: <http://trac.webkit.org/changeset/105497>
(In reply to comment #6) > Committed r105497: <http://trac.webkit.org/changeset/105497> Reopen, because it was rolled out by http://trac.webkit.org/changeset/105504
Created attachment 123315 [details] Patch Fix the leak in the layout tests and the GTK build hang. The growing memory problem was caused by the rendered tiles accumulating in the LayerTreeHostProxy since there is no painting in WebKitTestRunner. They would previously be dropped since no LayerTreeHostProxy was created yet but the web process would still waste time rendering. This is fixed by making sure that RenderNextFrame and DidRenderFrame are cycling. The GTK hang was caused by the default value for forceCompositingMode to be poorly defined with a default value of true, it's fixed now.
Comment on attachment 123315 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=123315&action=review > Source/WebKit2/ChangeLog:14 > + This patch also fix the flow of DidRenderFrame and RenderNextFrame messages fix -> fixes > Source/WebKit2/ChangeLog:40 > +2012-01-13 Jocelyn Turcotte <jocelyn.turcotte@nokia.com> > + > + ?
Committed r105517: <http://trac.webkit.org/changeset/105517>