Support subpixel layout for borders.

third_party/WebKit/Source/core/style/BorderValue.h

 /*
  * Copyright (C) 2000 Lars Knoll (knoll@kde.org)
  *           (C) 2000 Antti Koivisto (koivisto@kde.org)
  *           (C) 2000 Dirk Mueller (mueller@kde.org)
  * Copyright (C) 2003, 2005, 2006, 2007, 2008 Apple Inc. All rights reserved.
  * Copyright (C) 2006 Graham Dennis (graham.dennis@gmail.com)
  *
  * This library is free software; you can redistribute it and/or
  * modify it under the terms of the GNU Library General Public
  * License as published by the Free Software Foundation; either
@@ skipping 21 matching lines @@
 
 namespace blink {
 
 class BorderValue {
   DISALLOW_NEW();
   friend class ComputedStyle;
 
  public:
   BorderValue()
       : m_color(0),
+        m_width(3),
         m_colorIsCurrentColor(true),
-        m_width(3),
         m_style(BorderStyleNone),
         m_isAuto(OutlineIsAutoOff) {}
 
   bool nonZero() const { return width() && (m_style != BorderStyleNone); }
 
   bool isTransparent() const {
     return !m_colorIsCurrentColor && !m_color.alpha();
   }
 
   bool operator==(const BorderValue& o) const {
@@ skipping 17 matching lines @@
   void setColor(const StyleColor& color) {
     m_color = color.resolve(Color());
     m_colorIsCurrentColor = color.isCurrentColor();
   }
 
   StyleColor color() const {
     return m_colorIsCurrentColor ? StyleColor::currentColor()
                                  : StyleColor(m_color);
   }
 
-  int width() const { return m_width; }
+  float width() const { return m_width; }

[pdr., 2017/01/24 06:57:31]

I'm a little worried about the compatibility of this change with other browsers.
I did some testing and the landscape looks like:
FF: matches our current behavior
WebKit: matches our current behavior
Edge: matches the proposed behavior

Do you think it makes sense to try contacting the other browsers to see if we
can move unilaterally on this? I wasn't able to find any spec language around
this. I think it would be worth contacting a spec author just to ask since
border width is a little special to begin with.

[Karl Øygard, 2017/01/24 22:42:58]

I'm trying to figure out how WebKit and FF are handling subpixel layout--it's
not completely obvious.  FF doesn't appear to support subpixel borders, while
WebKit floors to nearest device pixel. I'll dig some more.

I aligned the code with Edge, for the simple reason that Blink's implementation
of subpixel layout is currently most similar to Edge.  I agree that this may
warrant an opinion from a spec author, I'll see what I can do about that.

 
   EBorderStyle style() const { return static_cast<EBorderStyle>(m_style); }
   void setStyle(EBorderStyle style) { m_style = style; }
 
  protected:
   Color m_color;
+  float m_width;

[pdr., 2017/01/24 06:57:31]

What range of values does this need to store? I don't think we should
prematurely optimize this, but an option is to used a fixed-point representation
like LayoutUnit.

[pdr., 2017/01/24 19:52:12]

Looking at this a bit closer... border width is only storing an unsigned short
value (aka 8 bits) but has 26 bits reserved below. I think it would be possible
to use LayoutUnit's fixed point approach while still having the same range of
values for this width, and without increasing the size of this object.

[Karl Øygard, 2017/01/24 22:42:58]

Unless I overlooked something, outline-width uses unsigned short, while borders
use unsigned int.  I don't really see a very good reason to allow borders to be
that large, though, so I agree that it might be worthwhile to use an approach
similar to LayoutUnit.

Should I do that here, or is that better suited for a separate patch?

   unsigned m_colorIsCurrentColor : 1;
 
-  unsigned m_width : 26;
   unsigned m_style : 4;  // EBorderStyle
 
   // This is only used by OutlineValue but moved here to keep the bits packed.
   unsigned m_isAuto : 1;  // OutlineIsAuto
 };
 
 }  // namespace blink
 
 #endif  // BorderValue_h