[layoutng] Support computing min-content and max-content

third_party/WebKit/Source/core/layout/ng/ng_box.h

Index: third_party/WebKit/Source/core/layout/ng/ng_box.h
diff --git a/third_party/WebKit/Source/core/layout/ng/ng_box.h b/third_party/WebKit/Source/core/layout/ng/ng_box.h
index a402ad24c2b1cde35a50da3d5d4b05ffe32b9f1e..5f1003250d8ad7862de6736f3b61602b446be4ed 100644
--- a/third_party/WebKit/Source/core/layout/ng/ng_box.h
+++ b/third_party/WebKit/Source/core/layout/ng/ng_box.h
@@ -32,6 +32,11 @@ class CORE_EXPORT NGBox final : public GarbageCollectedFinalized<NGBox> {
   // TODO(layout-ng): Should we have a StartLayout function to avoid passing
   // the same space for each Layout iteration?
   bool Layout(const NGConstraintSpace*, NGFragment**);
+
+  // Computes the value of min-content and max-content for this box.
+  void ComputeMinAndMaxContentSizes(NGFragment** min_content,

[eae, 2016/10/31 19:30:26]

Shouldn't this return rects or values? Returning a fragment seems odd unless we
plan to reuse the min/max fragments somehow.

[cbiesinger, 2016/10/31 19:48:37]

I also prefer LayoutUnit but I thought we agreed in the meeting to return
fragments? Ian, any thoughts?

[Gleb Lanbin, 2016/10/31 19:52:47]

IMO returning std::pair<NGFragment*, NGFragment*> would be a little bit more
appropriate here. 

[ikilpatrick, 2016/11/01 15:35:11]

I'm ok with returning a pair of layout units if people think this is a little
too much at the moment. This should be a pretty easy decision to revist later
on.

The idea with reusing fragments is that this would be easier for caching. I.e.
if (most) things just go through the Layout() calls and produce fragments, we
can re-use parts of the min/max content sizes as needed.

One question, what (should) happen with mixed writing modes content sizes?
Fragments here may be easier for mixed writing modes?

[atotic, 2016/11/01 16:59:00]

This API will call Layout() in a tight loop, which makes it blocking layout.

Is this final, or just temporary? I assume it is temporary because we do not
want blocking.

[cbiesinger, 2016/11/01 19:10:04]

Collective answer to all the comments:
- I dislike pair because it doesn't tell you which is which but I did make it a
struct, which has some other advantages (ie. can pass to ResolveInlineSize,
etc.)
- Not convinced how much Fragments would help with caching -- you can't mix them
with "regular" fragments as there's no constraint space. If you synthesize a
constraint space for caching, you'd still have problems because this function
transforms the layout fragments a bit so that Width and Height work as expected.

I realized this does not address writing modes (oops), adding a TODO for now.
But I think that is better solved by the caller deciding between Layout and
ComputeMinAndMax because this function would still want to avoid computing block
sizes in the common case for performance reasons.

- Good point on making this function interruptible. I think you're right that I
should do that. I made the enum a tri-state one (this also means I can't use the
std::optional suggestion) and changed the NGBox function accordingly.

+                                    NGFragment** max_content);
+
   const ComputedStyle* Style() const;
 
   NGBox* NextSibling();
@@ -41,12 +46,7 @@ class CORE_EXPORT NGBox final : public GarbageCollectedFinalized<NGBox> {
   void SetNextSibling(NGBox*);
   void SetFirstChild(NGBox*);
 
-  DEFINE_INLINE_VIRTUAL_TRACE() {
-    visitor->trace(algorithm_);
-    visitor->trace(fragment_);
-    visitor->trace(next_sibling_);
-    visitor->trace(first_child_);
-  }
+  DECLARE_VIRTUAL_TRACE();
 
  private:
   // This is necessary for interop between old and new trees -- after our parent