[New Multicolumn] Handle flow thread overflow correctly in flipped writing modes.

Source/core/layout/LayoutFlowThread.cpp

Index: Source/core/layout/LayoutFlowThread.cpp
diff --git a/Source/core/layout/LayoutFlowThread.cpp b/Source/core/layout/LayoutFlowThread.cpp
index 48f267bb8bc4ffa8c5c086f85bf2287c905dc1d6..7f08161e9b18ea818d91b9c5b6a1aacda78999e5 100644
--- a/Source/core/layout/LayoutFlowThread.cpp
+++ b/Source/core/layout/LayoutFlowThread.cpp
@@ -96,7 +96,12 @@ void LayoutFlowThread::validateRegions()
 void LayoutFlowThread::mapRectToPaintInvalidationBacking(const LayoutLayerModelObject* paintInvalidationContainer, LayoutRect& rect, const PaintInvalidationState* paintInvalidationState) const
 {
     ASSERT(paintInvalidationContainer != this); // A flow thread should never be an invalidation container.
+    // |rect| is a layout rectangle, where the block direction coordinate is flipped for writing
+    // mode. fragmentsBoundingBox(), on the other hand, works on physical rectangles, so we need to
+    // flip the rectangle before and after calling it.
+    flipForWritingMode(rect);
     rect = fragmentsBoundingBox(rect);
+    flipForWritingMode(rect);

[dsinclair, 2015/02/18 21:00:29]

I'm not sure I understand why this works. When we call flipWritingMode I believe
we end up in RenderBox.h::flipWritingMode(LayoutRect& rect). Looking at the
code, it will modify the X or Y value of the rect, but it doesn't change the
setting of the writing mode. So, when we call back in, won't we just adjust the
value a second time in exactly the same way, or, more likely, what did I miss?

[mstensho (USE GERRIT), 2015/02/18 22:25:41]

Yes, except that you have a fragmentsBoundingBox() call in the middle, which
does something to the rectangle. :)

flipForWritingMode() converts between layout rectangles and physical rectangles.
If the input is physical, it becomes a layout rectangle. If the input is a
layout rectangle, it becomes physical. It doesn't really care what the input is,
since in either case, all it needs to do is flip one coordinate (and even that
only if writing mode is vertical-rl or horizontal-bt).

In most of the layout code (e.g. RenderBox::m_frameRect or the rectangles in
RenderOverflow) the rectangles are _almost_ physical, but not quite (so we don't
call them physical): the block progression coordinate (y in horizontal writing
modes, x in vertical writing modes) is always the "logical top" - i.e. the block
coordinate where it starts in its container. If e.g. blocks go from right to
left, the x coordinate will represent the right edge of the box, relatively to
the right edge of its container. This is what we need to flip (to be physical,
we need x to represent the left edge of the box relatively to the left edge of
its container).

In other parts of the code (e.g. most of Layer, and when you get close to
actually painting something), rectangles are physical, so that they represent
what you're actually going to see on the screen.

So we use flipForWritingMode() to get from one rectangle type to the other.

mapRectToPaintInvalidationBacking() works with layout rectangles, while
fragmentsBoundingBox() works with physical ones, so we need to:

1. Convert the rectangle to physical
2. Let fragmentsBoundingBox() do its job on the physical rectangle (if you care
to know, it will convert from a physical flow thread rectangle to a physical
visual multicol rectangle. [1])
3. Convert the resulting rectangle to a layout rectangle, since that's what
mapRectToPaintInvalidationBacking() uses.

[1] I've attempted to explain the difference between flow thread and visual
coordinates/rectangles here:
http://www.chromium.org/developers/design-documents/multi-column-layout

     RenderBlockFlow::mapRectToPaintInvalidationBacking(paintInvalidationContainer, rect, paintInvalidationState);
 }