76061 2012-01-11 07:44:47 -0800 [Qt][WK2] css3/filters/should-not-have-compositing-layer.html is failing since added in 104622 2012-06-05 09:12:45 -0700 1 1 1 Unclassified WebKit WebKit2 528+ (Nightly build) Unspecified Unspecified RESOLVED DUPLICATE 88337 LayoutTestFailure, Qt, QtTriaged P2 Normal --- 1 kbalazs webkit-unassigned noam ossy steffen.imhof webkit-sed oldest_to_newest 533891 0 kbalazs 2012-01-11 07:44:47 -0800 Added in http://trac.webkit.org/changeset/104622. We composite some content that we should not. -PASS no compositing layers +FAIL content has compositing layers +(GraphicsLayer +(bounds 800.00 600.00) +(children 1 +(GraphicsLayer +(bounds 800.00 600.00) +) +) +) 533894 1 kbalazs 2012-01-11 07:51:18 -0800 Skipped in http://trac.webkit.org/changeset/104712 638339 2 steffen.imhof 2012-05-31 06:36:06 -0700 I had a look into this and noticed the content of the test page does not really matter. For me it looks as if compositing is always enabled in the Qt/WK2 case: In QQuickWebViewPrivate::initialize() there is: webPageProxy->pageGroup()->preferences()->setForceCompositingMode(true); and in DrawingAreaImpl's constructor: if (webPage->corePage()->settings()->acceleratedDrawingEnabled() || webPage->corePage()->settings()->forceCompositingMode()) m_alwaysUseCompositing = true; if (m_alwaysUseCompositing) enterAcceleratedCompositingMode(0); Furthermore QQuickWebPage is unconditionally expecting a LayerTreeHostProxy in QQuickWebPagePrivate::paint(): LayerTreeHostProxy* layerTreeHostProxy = webPageProxy->drawingArea()->layerTreeHostProxy(); if (layerTreeHostProxy->layerTreeRenderer()) So when I testwise changed the preference to setForceCompositingMode(false), QQuickWebPage got a NULL pointer and MiniBrowser instantly crashed for me. Now I am not sure, if this is by-design and it is ok to always have compositing enabled. Or if this more general issue still needs fixing (but that would probably be a bit too much for me). 638380 3 kbalazs 2012-05-31 07:11:55 -0700 (In reply to comment #2) > I had a look into this and noticed the content of the test page does not really matter. For me it looks as if compositing is always enabled in the Qt/WK2 case: > > In QQuickWebViewPrivate::initialize() there is: > webPageProxy->pageGroup()->preferences()->setForceCompositingMode(true); > > and in DrawingAreaImpl's constructor: > > if (webPage->corePage()->settings()->acceleratedDrawingEnabled() || webPage->corePage()->settings()->forceCompositingMode()) > m_alwaysUseCompositing = true; > > if (m_alwaysUseCompositing) > enterAcceleratedCompositingMode(0); > > > Furthermore QQuickWebPage is unconditionally expecting a LayerTreeHostProxy in QQuickWebPagePrivate::paint(): > > LayerTreeHostProxy* layerTreeHostProxy = webPageProxy->drawingArea()->layerTreeHostProxy(); > if (layerTreeHostProxy->layerTreeRenderer()) > > So when I testwise changed the preference to setForceCompositingMode(false), QQuickWebPage got a NULL pointer and MiniBrowser instantly crashed for me. > > Now I am not sure, if this is by-design and it is ok to always have compositing enabled. Or if this more general issue still needs fixing (but that would probably be a bit too much for me). Thanks for your time investigating on this. Yes, by design Qt-WK2 always use compositing. I think we should skip this patch and those that are testing for compositing is not turned on. 638384 4 kbalazs 2012-05-31 07:13:55 -0700 Oops, I just realized that the one who reported this is me... Noam, do you agree that we should skip all tests that tests for compositing is _not_ turned on (because we always use it)? 638390 5 noam 2012-05-31 07:23:58 -0700 (In reply to comment #4) > Oops, I just realized that the one who reported this is me... Noam, do you agree that we should skip all tests that tests for compositing is _not_ turned on (because we always use it)? Yes, sounds right. 641626 6 kbalazs 2012-06-05 09:12:45 -0700 I could not find any other test that explicitly test for compositing not turned on, however I filed a meta bug for this. *** This bug has been marked as a duplicate of bug 88337 ***