[SPV2] Implement the blink-side scroll property tree

third_party/WebKit/Source/platform/graphics/paint/ScrollPaintPropertyNode.h

Index: third_party/WebKit/Source/platform/graphics/paint/ScrollPaintPropertyNode.h
diff --git a/third_party/WebKit/Source/platform/graphics/paint/ScrollPaintPropertyNode.h b/third_party/WebKit/Source/platform/graphics/paint/ScrollPaintPropertyNode.h
new file mode 100644
index 0000000000000000000000000000000000000000..adcc08feeac994f2e30209f30024e05b278e1c37
--- /dev/null
+++ b/third_party/WebKit/Source/platform/graphics/paint/ScrollPaintPropertyNode.h
@@ -0,0 +1,97 @@
+// Copyright 2016 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef ScrollPaintPropertyNode_h
+#define ScrollPaintPropertyNode_h
+
+#include "platform/PlatformExport.h"
+#include "platform/geometry/FloatSize.h"
+#include "platform/graphics/paint/TransformPaintPropertyNode.h"
+#include "wtf/PassRefPtr.h"
+#include "wtf/RefCounted.h"
+#include "wtf/RefPtr.h"
+
+#include <iosfwd>
+
+namespace blink {
+
+// A scroll node contains auxiliary scrolling information for compositor-thread
+// scrolling and includes how far an area can be scrolled, which
+// |TransformPaintPropertyNode| contains the scroll offset, etc.
+class PLATFORM_EXPORT ScrollPaintPropertyNode : public RefCounted<ScrollPaintPropertyNode> {
+public:
+    static PassRefPtr<ScrollPaintPropertyNode> create(
+        PassRefPtr<const ScrollPaintPropertyNode> parent,
+        PassRefPtr<const TransformPaintPropertyNode> scrollOffsetTranslation,
+        const FloatSize& clip,
+        const FloatSize& bounds,
+        bool userScrollableHorizontal,
+        bool userScrollableVertical)
+    {
+        return adoptRef(new ScrollPaintPropertyNode(parent, scrollOffsetTranslation, clip, bounds, userScrollableHorizontal, userScrollableVertical));
+    }
+
+    void update(PassRefPtr<const ScrollPaintPropertyNode> parent, PassRefPtr<const TransformPaintPropertyNode> scrollOffsetTranslation, const FloatSize& clip, const FloatSize& bounds, bool userScrollableHorizontal, bool userScrollableVertical)
+    {
+        m_parent = parent;
+        DCHECK(scrollOffsetTranslation->matrix().isIdentityOr2DTranslation());
+        m_scrollOffsetTranslation = scrollOffsetTranslation;
+        m_clip = clip;
+        m_bounds = bounds;
+        m_userScrollableHorizontal = userScrollableHorizontal;
+        m_userScrollableVertical = userScrollableVertical;
+    }
+
+    const ScrollPaintPropertyNode* parent() const { return m_parent.get(); }
+
+    // Transform that the scroll is relative to.
+    const TransformPaintPropertyNode* scrollOffsetTranslation() const { return m_scrollOffsetTranslation.get(); }
+
+    // The clipped area that contains the scrolled content. In the common case
+    // this is the area that could respond to user input.

[trchen, 2016/09/07 23:12:53]

Why is this needed in the scroll node? I think the "geometry property states"
are enough to do perform hit testing. Also a rect is not complete without a base
transform space.

I'm guessing is it used to determine the scroll extent?
i.e. scroll_extent = deconvolute(bounds, clip)

[pdr., 2016/09/08 02:29:41]

That's a good point. I think we should remove the hit testing part of this
comment and just refer to the scrolling clip extents aspect.

I've updated this comment in the latest patch.

+    const FloatSize& clip() const { return m_clip; }
+
+    // The bounds of the content that is scrolled.
+    const FloatSize& bounds() const { return m_bounds; }

[trchen, 2016/09/07 23:12:53]

Not sure if it should be a Rect or a Size.

There are two scroll coordinate systems in Blink. The one used by ScrollableArea
[minPos, maxPos], and a shifted one used by Scrollbar (and I think cc use it
too) [0, maxPos - minPos]. Most of the time they are the same as minPos would be
0, but with special writing-mode it may not be the case.

For example:
<div style="direction:rtl; width:400px; height:300px; overflow:scroll;">
    <div style="width:1000px; height:1000px;"></div>
</div>

The layout overflow rect would be (l=-600, t=0, r=400, b=1000) and the scroll
extent would be (l=-600, t=0, r=0, b=600).
----
Another thing I still haven't think through is whether this should be FloatRect
or LayoutRect or IntRect.

Traditionally DOM only supports integer boxes and integer scroll range/offsets.
For smooth scrolling on high-DPI devices we allow fractional scroll delta (that
snaps to device pixels), but the nominal scroll offset is still integer I think.

I think it probably shouldn't be LayoutRect. Layout units should be internal to
layout and we only allowed them to leak up to paint.

It also involves another dilemma that we delay snapping until painting, but
determining scrollableness and scroll extent needs to be done in layout.

Here is an example of the dilemma: http://jsbin.com/jetaza/

It can be seen that the bottom border of the red box is clipped by its parent,
but the parent didn't create a scrollbar despite that it has overflow:auto.
(Even with scroll-y:scroll, the scrollbar is still disabled.)

[pdr., 2016/09/08 02:29:41]

+1, you've thought through this! cc's ScrollNode does have an offset
("offset_to_transform_parent") that essentially makes this a rect instead of a
size.

I haven't prototyped this, but my high-level thinking is that we can avoid the
complexity of needing an offset by creating a transform node for the scrollbars.
This would also come in handy for geometry mapper to handle hit testing of
scrollbars. Thoughts?
Excellent points! For the initial release of SPV2 I think we should strive to
match existing behavior. This approach makes a lot of stuff easier, such as not
needing two sets of expected layout tests. It's clear there is room for
improvement here though.

In the latest patch I've switched to using an IntSize which matches both the
inputs from the layout tree and the outputs in cc's ScrollNode.

+
+    bool userScrollableHorizontal() const { return m_userScrollableHorizontal; }
+    bool userScrollableVertical() const { return m_userScrollableVertical; }
+
+private:
+    ScrollPaintPropertyNode(
+        PassRefPtr<const ScrollPaintPropertyNode> parent,
+        PassRefPtr<const TransformPaintPropertyNode> scrollOffsetTranslation,
+        FloatSize clip,
+        FloatSize bounds,
+        bool userScrollableHorizontal,
+        bool userScrollableVertical)
+        : m_parent(parent)
+        , m_scrollOffsetTranslation(scrollOffsetTranslation)
+        , m_clip(clip)
+        , m_bounds(bounds)
+        , m_userScrollableHorizontal(userScrollableHorizontal)
+        , m_userScrollableVertical(userScrollableVertical)
+    {
+        DCHECK(m_scrollOffsetTranslation->matrix().isIdentityOr2DTranslation());
+    }
+
+    RefPtr<const ScrollPaintPropertyNode> m_parent;
+    RefPtr<const TransformPaintPropertyNode> m_scrollOffsetTranslation;
+    FloatSize m_clip;
+    FloatSize m_bounds;
+    bool m_userScrollableHorizontal;
+    bool m_userScrollableVertical;
+    // TODO(pdr): Add main thread scrolling reasons.
+    // TODO(pdr): Add an offset for the clip and bounds to the transform.
+    // TODO(pdr): Add 2 bits for whether this is a viewport scroll node.
+    // TODO(pdr): Add a bit for whether this is affected by page scale.
+};
+
+// Redeclared here to avoid ODR issues.
+// See platform/testing/PaintPrinters.h.
+void PrintTo(const ScrollPaintPropertyNode&, std::ostream*);
+
+} // namespace blink
+
+#endif // ScrollPaintPropertyNode_h