Bug 76296 – [Qt] Trigger forcing accelerated compositing from the UI process side.

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Jocelyn Turcotte]

[Qt] Trigger forcing accelerated compositing from the UI process side.

[Jocelyn Turcotte]

Created attachment 122478 [details]
Patch

[Noam Rosenthal]

Comment on attachment 122478 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=122478&action=review

r=me with nitpicks

> Source/WebKit2/UIProcess/DrawingAreaProxyImpl.cpp:65
> +    // Construct the proxy early to allow messages to be sent to the web process ASAP.
> +    if (webPageProxy->pageGroup()->preferences()->forceCompositingMode())
> +        m_layerTreeHostProxy = adoptPtr(new LayerTreeHostProxy(this));
> +#endif

Instead of ASAP say when messages actually need to be sent, e.g. "before page load".

Put this in PLATFORM(QT), other ports with WebKit2+TextureMapper might not want this.

> Source/WebKit2/WebProcess/WebPage/DrawingAreaImpl.cpp:675
>      if (m_layerTreeHost)

You don't need this condition if you assert

[Jocelyn Turcotte]

(In reply to comment #2)
> Put this in PLATFORM(QT), other ports with WebKit2+TextureMapper might not want this.
The Qt platform isn't producing any specific behavior that isn't already covered by the forceCompositingMode() condition. I also like the benefit of having the texture mapper behaving as close as possible between ports to reduce the number of platform specific bugs and keep the code paths straightforward.

I fixed the other issues.

[Noam Rosenthal]

(In reply to comment #3)
> (In reply to comment #2)
> > Put this in PLATFORM(QT), other ports with WebKit2+TextureMapper might not want this.
> The Qt platform isn't producing any specific behavior that isn't already covered by the forceCompositingMode() condition. I also like the benefit of having the texture mapper behaving as close as possible between ports to reduce the number of platform specific bugs and keep the code paths straightforward.

Other ports that use texture-mapper don't have a LayerTreeHostProxy at this time. So generating a LayerTreeHostProxy for them at that point would break their webkit2.

[Jocelyn Turcotte]

(In reply to comment #4)
> Other ports that use texture-mapper don't have a LayerTreeHostProxy at this time. So generating a LayerTreeHostProxy for them at that point would break their webkit2.

As talked on IRC, this wouldn't be an issue as of today in trunk, so we can ifdef it out once it becomes a problem.

[Jocelyn Turcotte]

Committed r105497: <http://trac.webkit.org/changeset/105497>

[Csaba Osztrogonác]

(In reply to comment #6)
> Committed r105497: <http://trac.webkit.org/changeset/105497>

Reopen, because it was rolled out by http://trac.webkit.org/changeset/105504

[Jocelyn Turcotte]

Created attachment 123315 [details]
Patch

Fix the leak in the layout tests and the GTK build hang.
The growing memory problem was caused by the rendered tiles accumulating in the LayerTreeHostProxy since there is no painting in WebKitTestRunner. They would previously be dropped since no LayerTreeHostProxy was created yet but the web process would still waste time rendering. This is fixed by making sure that RenderNextFrame and DidRenderFrame are cycling.
The GTK hang was caused by the default value for forceCompositingMode to be poorly defined with a default value of true, it's fixed now.

[Noam Rosenthal]

Comment on attachment 123315 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=123315&action=review

> Source/WebKit2/ChangeLog:14
> +        This patch also fix the flow of DidRenderFrame and RenderNextFrame messages

fix -> fixes

> Source/WebKit2/ChangeLog:40
> [phone]  Jocelyn Turcotte  <[e-mail]>
> +
> +

?

[Jocelyn Turcotte]

Committed r105517: <http://trac.webkit.org/changeset/105517>