compositor-worker: plumb element id and mutable properties

third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp

Index: third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
diff --git a/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp b/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
index ff610fc7505eb5cb88eae2596ef7f27a8ba0df42..1c8fa0a61a9a6f9903efe0029c8c4ca9647dad6c 100644
--- a/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
+++ b/third_party/WebKit/Source/core/css/resolver/StyleAdjuster.cpp
@@ -49,6 +49,7 @@
 #include "core/svg/SVGSVGElement.h"
 #include "platform/Length.h"
 #include "platform/transforms/TransformOperations.h"
+#include "public/platform/WebCompositorMutableProperties.h"
 #include "wtf/Assertions.h"
 
 namespace blink {
@@ -181,6 +182,21 @@ void StyleAdjuster::adjustComputedStyle(ComputedStyle& style, const ComputedStyl
         adjustStyleForFirstLetter(style);
     }
 
+    if (element && element->hasCompositorProxy()) {

[chrishtr, 2015/11/24 16:22:50]

Factor into another method, this one is getting too long.

[Ian Vollick, 2015/11/25 18:28:44]

Done.

+        TRACE_EVENT0(TRACE_DISABLED_BY_DEFAULT("compositor-worker"), "StyleAdjuster::adjustComputedStyle hasCompositorProxy");
+
+        style.setHasCompositorProxy(true);
+        uint32_t mutableProperties = element->mutableProperties();
+        if (mutableProperties & (WebCompositorMutablePropertyScrollTop | WebCompositorMutablePropertyScrollLeft))
+            style.setWillChangeScrollPosition(true);

[ajuma, 2015/11/20 21:55:27]

will-change:scroll-position doesn't currently create a composited layer (or do
anything really), so you'll need to change
ComputeStyle::hasWillChangeCompositedHint. Also, will-change doesn't directly
force a PaintLayer (unless the property being will-changed is one that creates a
stacking context, in which case the computed z-index gets set to 0 which forces
a PaintLayer), but I guess if the thing is really overflow:scroll you'll already
have one.

[Ian Vollick, 2015/11/23 20:25:54]

Ah, whoops. Yes, the composited layer _doesn't_ actually depend on will-chang.
That was handled in a previous CL
(https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit...).

[chrishtr, 2015/11/24 16:22:50]

Was Ali's comment addressed? Not sure how to read your response.

Also, doesn't setting values in this function cause a developer-visible side
effect (will-change: scroll-position in ComputedStyle) even if CompositorWorker
is not web-exposed?

Please also unittest this function.

[Ian Vollick, 2015/11/25 18:28:44]

I was trying to say that will-change does not play a role in getting proxied
elements promoted. I.e., will-change is not required for the code to work.

I'd wanted proxies to imply will change because having a proxy pointed at a
property truly does mean that you will-change it. It would be helpful for the
engine to know this in case it wanted to make optimizations.

That said, you're right that this behavior will be developer visible when we
implement snap and sticky in terms of compositor worker. Since this will-change
business is really just an optimization for when (and if) CW is web exposed,
I've removed it from this patch.

+        Vector<CSSPropertyID> properties = style.willChangeProperties();
+        if ((mutableProperties & WebCompositorMutablePropertyOpacity) && !properties.contains(CSSPropertyOpacity))
+            properties.append(CSSPropertyOpacity);
+        if ((mutableProperties & WebCompositorMutablePropertyTransform) && !properties.contains(CSSPropertyTransform))
+            properties.append(CSSPropertyTransform);
+        style.setWillChangeProperties(properties);
+    }
+
     // Make sure our z-index value is only applied if the object is positioned.
     if (style.position() == StaticPosition && !parentStyleForcesZIndexToCreateStackingContext(parentStyle))
         style.setHasAutoZIndex();