Generate scroll/clip display item hierarchy for SPv2

Source/platform/graphics/paint/DisplayItem.h

Index: Source/platform/graphics/paint/DisplayItem.h
diff --git a/Source/platform/graphics/paint/DisplayItem.h b/Source/platform/graphics/paint/DisplayItem.h
index 0da40fce703c9f7abcd21454f36ee1eb15d5ac22..d4d107ddbd4180d2e1527713cc47c3277c6f746b 100644
--- a/Source/platform/graphics/paint/DisplayItem.h
+++ b/Source/platform/graphics/paint/DisplayItem.h
@@ -112,6 +112,7 @@ public:
         ClipColumnBoundsPaintPhaseLast = ClipColumnBoundsPaintPhaseFirst + PaintPhaseMax,
         ClipLayerFragmentPaintPhaseFirst,
         ClipLayerFragmentPaintPhaseLast = ClipLayerFragmentPaintPhaseFirst + PaintPhaseMax,
+        ClipDescendantStackingContext,
         ClipFileUploadControlRect,
         ClipFrameToVisibleContentRect,
         ClipFrameScrollbars,
@@ -161,8 +162,7 @@ public:
         EndClipPath,
         BeginFixedPosition,
         EndFixedPosition,
-        BeginFixedPositionContainer,
-        EndFixedPositionContainer,
+        FixedPositionContainer,

[pdr., 2015/09/03 06:16:59]

Won't we still need begin/end pairs for multiple fixed-pos containers (nested,
or not). For example: http://jsfiddle.net/progers/euhb41Lf/1

Can we pull the fixed pos logic into a separate patch, maybe after the big one?
I think the direction looks good overall, just want to simplify this patch.

[trchen, 2015/09/04 06:10:15]

Previously when I added it I was thinking the fixed-pos container will establish
a scope, and fixed-pos display item will refer to the innermost enclosing one.

Now I think the anchor/warp is a simpler approach (also more flexible). We may
rename them to [Anchor|Warp]DisplayItem in the future if we also want to
implement de-duping for O(n^2) scroll display item problem.
Sure we can! Just that fixed-pos will be broken in the meantime.

 
         BeginSubsequence,
         EndSubsequence,