Column balancing refactoring. Don't propagate data during layout.

third_party/WebKit/Source/core/layout/LayoutMultiColumnFlowThread.h

 /*
  * Copyright (C) 2012 Apple Inc.  All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
  * modification, are permitted provided that the following conditions
  * are met:
  * 1. Redistributions of source code must retain the above copyright
  *    notice, this list of conditions and the following disclaimer.
  * 2. Redistributions in binary form must reproduce the above copyright
  *    notice, this list of conditions and the following disclaimer in the
@@ skipping 83 matching lines @@
 // More on column balancing: the columns' height is unknown in the first layout pass when
 // balancing. This means that we cannot insert any implicit (soft / unforced) breaks (and pagination
 // struts) when laying out the contents of the flow thread. We'll just lay out everything in tall
 // single strip. After the initial flow thread layout pass we can determine a tentative / minimal /
 // initial column height. This is calculated by simply dividing the flow thread's height by the
 // number of specified columns. In the layout pass that follows, we can insert breaks (and
 // pagination struts) at column boundaries, since we now have a column height. It may very easily
 // turn out that the calculated height wasn't enough, though. We'll notice this at end of layout. If
 // we end up with too many columns (i.e. columns overflowing the multicol container), it wasn't
 // enough. In this case we need to increase the column heights. We'll increase them by the lowest
-// amount of space that could possibly affect where the breaks occur (see
-// LayoutMultiColumnSet::recordSpaceShortage()). We'll relayout (to find new break points and the
-// new lowest amount of space increase that could affect where they occur, in case we need another
-// round) until we've reached an acceptable height (where everything fits perfectly in the number of
-// columns that we have specified). The rule of thumb is that we shouldn't have to perform more of
-// such iterations than the number of columns that we have.
+// amount of space that could possibly affect where the breaks occur. We'll relayout (to find new
+// break points and the new lowest amount of space increase that could affect where they occur, in
+// case we need another round) until we've reached an acceptable height (where everything fits
+// perfectly in the number of columns that we have specified). The rule of thumb is that we
+// shouldn't have to perform more of such iterations than the number of columns that we have.
 //
 // For each layout iteration done for column balancing, the flow thread will need a deep layout if
 // column heights changed in the previous pass, since column height changes may affect break points
 // and pagination struts anywhere in the tree, and currently no way exists to do this in a more
 // optimized manner.
 //
 // There's also some documentation online:
 // https://sites.google.com/a/chromium.org/dev/developers/design-documents/multi-column-layout
 class CORE_EXPORT LayoutMultiColumnFlowThread : public LayoutFlowThread {
 public:
@@ skipping 100 matching lines @@
 
     void addColumnSetToThread(LayoutMultiColumnSet*) override;
     void willBeRemovedFromTree() override;
     void flowThreadDescendantWasInserted(LayoutObject*) final;
     void flowThreadDescendantWillBeRemoved(LayoutObject*) final;
     void flowThreadDescendantStyleWillChange(LayoutBox*, StyleDifference, const ComputedStyle& newStyle) override;
     void flowThreadDescendantStyleDidChange(LayoutBox*, StyleDifference, const ComputedStyle& oldStyle) override;
     void computePreferredLogicalWidths() override;
     void computeLogicalHeight(LayoutUnit logicalHeight, LayoutUnit logicalTop, LogicalExtentComputedValues&) const override;
     void updateLogicalWidth() override;
-    void setPageBreak(LayoutUnit offset, LayoutUnit spaceShortage) override;
+    void contentWasLaidOut(LayoutUnit logicalTopInFlowThreadAfterPagination) override;
     void updateMinimumPageHeight(LayoutUnit offset, LayoutUnit minHeight) override;
-    bool addForcedColumnBreak(LayoutUnit, LayoutObject* breakChild, bool isBefore, LayoutUnit* offsetBreakAdjustment = nullptr) override;
 
     // The last set we worked on. It's not to be used as the "current set". The concept of a
     // "current set" is difficult, since layout may jump back and forth in the tree, due to wrong
     // top location estimates (due to e.g. margin collapsing), and possibly for other reasons.
     LayoutMultiColumnSet* m_lastSetWorkedOn;
 
     unsigned m_columnCount; // The used value of column-count
     LayoutUnit m_columnHeightAvailable; // Total height available to columns, or 0 if auto.
 
     // Cached block offset from this flow thread to the enclosing flow thread, if any. In the
     // coordinate space of the enclosing flow thread.
     LayoutUnit m_blockOffsetInEnclosingFlowThread;
 
     bool m_inBalancingPass; // Set when relayouting for column balancing.
     bool m_needsColumnHeightsRecalculation; // Set when we need to recalculate the column set heights after layout.
     bool m_progressionIsInline; // Always true for regular multicol. False for paged-y overflow.
     bool m_isBeingEvacuated;
 };
 
 // Cannot use DEFINE_LAYOUT_OBJECT_TYPE_CASTS here, because isMultiColumnFlowThread() is defined in
 // LayoutFlowThread, not in LayoutObject.
 DEFINE_TYPE_CASTS(LayoutMultiColumnFlowThread, LayoutFlowThread, object, object->isLayoutMultiColumnFlowThread(), object.isLayoutMultiColumnFlowThread());
 
 } // namespace blink
 
 #endif // LayoutMultiColumnFlowThread_h