Draw infobar arrow border with width of 1px on any scale factor.

chrome/browser/ui/views/infobars/infobar_view.cc

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "chrome/browser/ui/views/infobars/infobar_view.h"
 
 #include <algorithm>
 #include <utility>
 
 #include "base/memory/scoped_ptr.h"
@@ skipping 176 matching lines @@
     SkScalar arrow_fill_half_width = SkIntToScalar(arrow_half_width());
     SkScalar separator_height =
         SkIntToScalar(InfoBarContainerDelegate::kSeparatorLineHeight);
     if (delegate->DrawInfoBarArrows(&arrow_x) && arrow_fill_height) {
       // Skia pixel centers are at the half-values, so the arrow is horizontally
       // centered at |arrow_x| + 0.5.  Vertically, the stroke path is the center
       // of the separator, while the fill path is a closed path that extends up
       // through the entire height of the separator and down to the bottom of
       // the arrow where it joins the bar.
       stroke_path_.moveTo(
           SkIntToScalar(arrow_x) + SK_ScalarHalf - arrow_fill_half_width,

[Peter Kasting, 2016/03/25 05:07:46]

This 0.5 adjustment is still going to be incorrect at larger scale factors.

I think if you construct the path here in px coordinates instead of dp, you'll
avoid this issue and avoid reintroducing the similar problem that led to your
most recent set of changes.  Plus the code might actually be slightly simpler
than constructing the path here, then scaling it and shifting it post-scale.

This would also open the door to making the other change I suggested earlier,
which would be to pretty much replace the fill_path_ computation code below with
a call to Op().  (But I'm not saying you have to do that, just that this would
be a necessary step along the way to getting there.)

[Evan Stade, 2016/03/28 21:44:36]

Yes, at 2x the point is 2px wide, but I don't think it looks bad:
https://screenshot.googleplex.com/VPof11VhcDZ.png
With higher pixel densities it should be hard to even notice the difference.
There's no way to get the DSF in Layout(). You can do something gross like 
GetDisplayNearestWindow(view).device_scale_factor(); but there's no guarantee
the display won't change between layout and paint (e.g. the user could drag the
browser window between monitors and the DSF would change but Layout might not be
called again). It seems better to keep this calculation in DP and make pixel
adjustments at paint time in InfobarBackground. See my latest patchset, which
produces https://screenshot.googleplex.com/9fNhzntPOyj.png (I believe these
screenshots demonstrate correctness at all shown scale factors)

[Peter Kasting, 2016/03/29 01:04:00]

At odd integral scale factors, the tip will look correct; the sides will have
slightly different angles, but that will be hard to spot.

At even integral scale factors, the above is true, plus the tip will basically
be split evenly across 2 px, which isn't great, but is not a huge deal.

But I'm kinda worried about e.g. 140% and other non-integral scale factors,
which AFAIK are common on Windows.
In other places, the way we do this when we have no canvas is by querying
GetWidget()->GetCompositor()->device_scale_factor().  However, I think your
concerns about layout have merit.

Looking more closely at this code, it looks like there's no real reason we have
to compute these paths in Layout() to begin with; no code in InfoBarView uses
them, they're just created for use in InfoBarBackground::Paint().

So what if we just rip all this code out of here and move the path calculation
entirely to that function?

This would presumably be a bit simpler overall and would give us maximum
flexibility in how to construct the paths.  I think these paths are simple
enough that we don't need to cache them anyway.

           SkIntToScalar(arrow_height()) - (separator_height * SK_ScalarHalf));
       stroke_path_.rLineTo(arrow_fill_half_width, -arrow_fill_height);
       stroke_path_.rLineTo(arrow_fill_half_width, arrow_fill_height);
 
       fill_path_ = stroke_path_;
-      // Move the top of the fill path up to the top of the separator and then
-      // extend it down all the way through.
-      fill_path_.offset(0, -separator_height * SK_ScalarHalf);
       // This 0.01 hack prevents the fill from filling more pixels on the right
       // edge of the arrow than on the left.
       const SkScalar epsilon = 0.01f;
       fill_path_.rLineTo(-epsilon, 0);
       fill_path_.rLineTo(0, separator_height);
       fill_path_.rLineTo(epsilon - (arrow_fill_half_width * 2), 0);
       fill_path_.close();
     }
   }
   if (bar_height()) {
-    fill_path_.addRect(
-        0.0, SkIntToScalar(arrow_height()), SkIntToScalar(width()),
-        SkIntToScalar(
-            height() - InfoBarContainerDelegate::kSeparatorLineHeight));
+    fill_path_.addRect(0.0, SkIntToScalar(arrow_height()),
+                       SkIntToScalar(width()), SkIntToScalar(height()));
   }
 
   child_container_->SetBounds(
       0, arrow_height(), width(),
       bar_height() - InfoBarContainerDelegate::kSeparatorLineHeight);
   // |child_container_| should be the only child.
   DCHECK_EQ(1, child_count());
 
   // Even though other views are technically grandchildren, we'll lay them out
   // here on behalf of |child_container_|.
@@ skipping 201 matching lines @@
 }
 
 bool InfoBarView::DoesIntersectRect(const View* target,
                                     const gfx::Rect& rect) const {
   DCHECK_EQ(this, target);
   // Only events that intersect the portion below the arrow are interesting.
   gfx::Rect non_arrow_bounds = GetLocalBounds();
   non_arrow_bounds.Inset(0, arrow_height(), 0, 0);
   return rect.Intersects(non_arrow_bounds);
 }