Bug 83816 – Fix the ACCELERATED_COMPOSITING code to not expose RenderLayer outside rendering

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Julien Chaffraix]

Currently the accelerated canvas, WebGL, accelerated transitions / animations and more generally the accelerated code path are needlessly exposing RenderLayer (and RenderLayerBacking) to different objects outside rendering.

Let's change that.

[Julien Chaffraix]

Created attachment 136968 [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.

[James Robinson]

Comment on attachment 136968 [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.

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

> Source/WebCore/rendering/RenderBoxModelObject.h:169
> +    void contentChanged(ContentChangeType);

Hm, so now RenderBoxModelObject has to know about composited content?

[Julien Chaffraix]

Comment on attachment 136968 [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.

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

>> Source/WebCore/rendering/RenderBoxModelObject.h:169
>> +    void contentChanged(ContentChangeType);
> 
> Hm, so now RenderBoxModelObject has to know about composited content?

Basically yes. So far, we have attached the concept of composition to RenderLayers but it's really a RenderObject decision (RenderLayer being the hook on which we attach our composition objects). Also as we are hiding RenderLayers as an implementation details to the rest of the code, I don't see (alternative suggestions welcome) another way than to push this knowledge down to the rendering hierarchy.

As we currently enable composition only for RenderBoxModelObjects, it made sense to add it here.

[WebKit Review Bot]

Comment on attachment 136968 [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.

Attachment 136968 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12392633

New failing tests:
svg/text/font-size-below-point-five.svg

[WebKit Review Bot]

Created attachment 136994 [details]
Archive of layout-test-results from ec2-cr-linux-02

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-02  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick

[Julien Chaffraix]

The cr-linux failure is svg/text/font-size-below-point-five.svg. I can reproduce the failure locally and it's not related to nor impacted by this patch.

[James Robinson]

Comment on attachment 136968 [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.

OK

[WebKit Review Bot]

Comment on attachment 136968 [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.

Clearing flags on attachment: 136968

Committed r114437: <http://trac.webkit.org/changeset/114437>

[WebKit Review Bot]

All reviewed patches have been landed.  Closing bug.