[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





--- Comment #3 from Balazs Kelemen <kbalazs at webkit.org>  2012-05-31 07:11:55 PST ---
(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.

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