Support subpixel layout for borders.

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

Index: third_party/WebKit/Source/core/style/BorderValue.h
diff --git a/third_party/WebKit/Source/core/style/BorderValue.h b/third_party/WebKit/Source/core/style/BorderValue.h
index 9c97bfcda155c9b0726d7f34fd3fa0df352cf24d..18b285a7087196d2080025670cccfc403b15d1d9 100644
--- a/third_party/WebKit/Source/core/style/BorderValue.h
+++ b/third_party/WebKit/Source/core/style/BorderValue.h
@@ -39,8 +39,8 @@ class BorderValue {
  public:
   BorderValue()
       : m_color(0),
-        m_colorIsCurrentColor(true),
         m_width(3),
+        m_colorIsCurrentColor(true),
         m_style(BorderStyleNone),
         m_isAuto(OutlineIsAutoOff) {}
 
@@ -78,16 +78,16 @@ class BorderValue {
                                  : 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.