Bug 76061 – [Qt][WK2] css3/filters/should-not-have-compositing-layer.html is failing since added in 104622

• Component: WebKit2
• Status: RESOLVED DUPLICATE

[Balazs Kelemen]

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)
+)
+)
+)

[Balazs Kelemen]

Skipped in http://trac.webkit.org/changeset/104712

[Steffen Imhof]

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).

[Balazs Kelemen]

(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.

[Balazs Kelemen]

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)?

[Noam Rosenthal]

(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.

[Balazs Kelemen]

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 ***