Bug 83816

Summary: Fix the ACCELERATED_COMPOSITING code to not expose RenderLayer outside rendering
Product: WebKit Reporter: Julien Chaffraix <jchaffraix@webkit.org>
Component: Layout and RenderingAssignee: Julien Chaffraix <jchaffraix@webkit.org>
Status: RESOLVED FIXED    
Severity: Normal CC: dglazkov@chromium.org, enne@google.com, eric.carlson@apple.com, eric@webkit.org, feature-media-reviews@chromium.org, jamesr@chromium.org, kbr@google.com, senorblanco@chromium.org, simon.fraser@apple.com, webkit.review.bot@gmail.com
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
Bug Depends on:    
Bug Blocks: 83811    
Attachments:
Description Flags
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.
none
Archive of layout-test-results from ec2-cr-linux-02 none

Description From 2012-04-12 13:33:08 PST
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.
------- Comment #1 From 2012-04-12 14:05:17 PST -------
Created an attachment (id=136968) [details]
Proposed refactoring 1: Added some methods on RenderBoxModelObject to abstract the need for a RenderLayer.
------- Comment #2 From 2012-04-12 14:28:23 PST -------
(From update of attachment 136968 [details])
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?
------- Comment #3 From 2012-04-12 15:16:06 PST -------
(From update of attachment 136968 [details])
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.
------- Comment #4 From 2012-04-12 16:26:16 PST -------
(From update of attachment 136968 [details])
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
------- Comment #5 From 2012-04-12 16:26:22 PST -------
Created an attachment (id=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
------- Comment #6 From 2012-04-12 17:25:20 PST -------
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.
------- Comment #7 From 2012-04-17 13:13:17 PST -------
(From update of attachment 136968 [details])
OK
------- Comment #8 From 2012-04-17 14:51:43 PST -------
(From update of attachment 136968 [details])
Clearing flags on attachment: 136968

Committed r114437: <http://trac.webkit.org/changeset/114437>
------- Comment #9 From 2012-04-17 14:51:58 PST -------
All reviewed patches have been landed.  Closing bug.