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

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=76061


Steffen Imhof <steffen.imhof at basyskom.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |steffen.imhof at basyskom.com




--- Comment #2 from Steffen Imhof <steffen.imhof at basyskom.com>  2012-05-31 06:36:06 PST ---
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).

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.