Make various gfx classes more amenable to use as compile-time constants.

ui/gfx/geometry/size_f.h

Index: ui/gfx/geometry/size_f.h
diff --git a/ui/gfx/geometry/size_f.h b/ui/gfx/geometry/size_f.h
index 2ee2f51973c635e96ad0236067d5ae9fedb88482..bde15e5f32f7b373ebb4a528afc6cb9be69108b6 100644
--- a/ui/gfx/geometry/size_f.h
+++ b/ui/gfx/geometry/size_f.h
@@ -18,17 +18,16 @@ namespace gfx {
 // A floating version of gfx::Size.
 class GFX_EXPORT SizeF {
  public:
-  SizeF() : width_(0.f), height_(0.f) {}
-  SizeF(float width, float height)
-      : width_(fmaxf(0, width)), height_(fmaxf(0, height)) {}
-  ~SizeF() {}
+  constexpr SizeF() : width_(0.f), height_(0.f) {}
+  constexpr SizeF(float width, float height)
+      : width_(width < 0 ? 0 : width), height_(height < 0 ? 0 : height) {}

[Peter Kasting, 2016/06/10 00:19:19]

This behavior will only differ when one of the provided values is NaN, which
didn't seem worrisome.

[danakj, 2016/06/10 00:36:48]

Hm. https://bugs.chromium.org/p/chromium/issues/detail?id=407444#c20

IIRC fmaxf > a<0?0:x > std::max(), but obviously doing it at compile time is
even better. I don't see fmaxf mentioned no that bug though either.

Would you mind watching some thread-cpu-times-per-frame perf tests when this
lands (or do a perf tryjob) to verify this is not a problem?

[Peter Kasting, 2016/06/10 05:50:06]

Is there somewhere that covers how to do this/what to look at?  I've never
looked at the things you mention so I'm not sure where to be looking.

Also, it turns out some tests rely on the NaN behavior.  Specifically,
QuadF::BoundingBox() can be called with e.g. the left and right edges both at
infinity, in which case the computed rect width is NaN, and the test expects
zero width.  I thought about modifying the test to expect the empty rect (which
is what we get if NaNs get returned from BoundingBox()), but that seemed wrong. 
(Perhaps this suggests that the caller shouldn't return the empty rect when it
detects NaN?)  I thought about modifying BoundingBox() to force inf - inf to be
0 instead of NaN, but that seemed like a hack.  Finally I put an explicit
isnan() check here -- which actually works since that function is constexpr.

This makes me a bit unhappy, though.

[Peter Kasting, 2016/06/10 07:03:18]

...except on MSVC.

F___.

OK, going back to my other options.  I don't want to just bail on making this
constexpr, since that will also cause everything using a SizeF to not be
constexpr.  And BoxF already uses a test like this without the isnan() check. 
So I think maybe it really is right to not do that check here.

So I've mucked with MathUtil::(Map,Project)EnclosingClipRect() so that when they
see NaN coords, they force them individually to zero instead of bailing and
returning an empty rect.  This changed some of the expected test results.

I can see an argument for why this behavior is actually more sane.  I can also
see an argument for leaving these functions untouched, and instead making the
calling tests expect empty rects in more cases.  And I can see other arguments
too.

In short, I am extremely uncertain that what I'm doing is ideal, but the
existing code kinda seems wrong (or at least "not intentionally constructed")
too.

 
-  explicit SizeF(const Size& size)
+  constexpr explicit SizeF(const Size& size)
       : SizeF(static_cast<float>(size.width()),
               static_cast<float>(size.height())) {}
 
-  float width() const { return width_; }
-  float height() const { return height_; }
+  constexpr float width() const { return width_; }
+  constexpr float height() const { return height_; }
 
   void set_width(float width) { width_ = fmaxf(0, width); }
   void set_height(float height) { height_ = fmaxf(0, height); }