Summary: | [Qt][WK2] css3/filters/should-not-have-compositing-layer.html is failing since added in 104622 | ||
---|---|---|---|
Product: | WebKit | Reporter: | Balazs Kelemen <kbalazs> |
Component: | WebKit2 | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | noam, ossy, steffen.imhof, webkit-sed |
Priority: | P2 | Keywords: | LayoutTestFailure, Qt, QtTriaged |
Version: | 528+ (Nightly build) | ||
Hardware: | Unspecified | ||
OS: | Unspecified |
Description
Balazs Kelemen
2012-01-11 07:44:47 PST
Skipped in http://trac.webkit.org/changeset/104712 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). (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. 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)? (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. |