Fix appearance of header row separators in table view at fractional

Fix appearance of header row separators in table view at fractional
scale factors.

BUG=688507
Review-Url: https://codereview.chromium.org/2689273002
Cr-Commit-Position: refs/heads/master@{#451107}
Committed: https://chromium.googlesource.com/chromium/src/+/7236fb9312cfeb76d7f0c195eb567c995143add5

[Evan Stade, 2017-02-13 22:59:22]

The CQ bit was checked by estade@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-02-13 22:59:55]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-14 01:15:13]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-14 01:15:14]

Dry run: This issue passed the CQ dry run.

[Evan Stade, 2017-02-14 23:06:03]

estade@chromium.org changed reviewers:
+ pkasting@chromium.org

[Evan Stade, 2017-02-14 23:06:04]

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc
File ui/gfx/canvas.cc (right):

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc#newcode335
ui/gfx/canvas.cc:335: flags.setStrokeWidth(std::floor(dsf));
I guess I could use gfx::ToFlooredInt for this, but what's wrong with
std::floor?

[Peter Kasting, 2017-02-15 00:44:00]

LGTM

I wonder if DrawLine() should do this by default.

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc
File ui/gfx/canvas.cc (right):

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc#newcode328
ui/gfx/canvas.cc:328: PointF start = p1;
Nit: If you're just going to copy these anyway, I suggest passing them to the
function by value and then scaling the args directly.  This lets the compiler be
more efficient in some cases (when caller structs don't have to be forced to the
stack).

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc#newcode335
ui/gfx/canvas.cc:335: flags.setStrokeWidth(std::floor(dsf));
On 2017/02/14 23:06:03, Evan Stade wrote:
> I guess I could use gfx::ToFlooredInt for this, but what's wrong with
> std::floor?

floor() returns a float, which is potentially outside the representable range
for an int (and also isn't an int typewise).

In this case, you're trying to convert back to a floating-point type anyway, so
I'd do SkFloatToScalar(std::floor()) instead of trying to go through
ToFlooredInt.

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.h
File ui/gfx/canvas.h (right):

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.h#newcode297
ui/gfx/canvas.h:297: void DrawSharpLine(const PointF& p1, const PointF& p2,
SkColor color);
Nit: Is "Sharp" the best name for this?  "DrawIntegralPxLine" maybe?  I can't
think of anything non-awkward, but when I read "Sharp" I assumed it meant a
hairline, if I knew what it meant at all.

[Evan Stade, 2017-02-15 16:54:47]

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc
File ui/gfx/canvas.cc (right):

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc#newcode328
ui/gfx/canvas.cc:328: PointF start = p1;
On 2017/02/15 00:43:59, Peter Kasting wrote:
> Nit: If you're just going to copy these anyway, I suggest passing them to the
> function by value and then scaling the args directly.  This lets the compiler
be
> more efficient in some cases (when caller structs don't have to be forced to
the
> stack).

I thought we never passed non-PODs by value and coverity at least used to
complain about that. Anyway I changed this and one other function in this file.

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.cc#newcode335
ui/gfx/canvas.cc:335: flags.setStrokeWidth(std::floor(dsf));
On 2017/02/15 00:43:59, Peter Kasting wrote:
> On 2017/02/14 23:06:03, Evan Stade wrote:
> > I guess I could use gfx::ToFlooredInt for this, but what's wrong with
> > std::floor?
> 
> floor() returns a float, which is potentially outside the representable range
> for an int (and also isn't an int typewise).
> 
> In this case, you're trying to convert back to a floating-point type anyway,
so
> I'd do SkFloatToScalar(std::floor()) instead of trying to go through
> ToFlooredInt.

Done.

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.h
File ui/gfx/canvas.h (right):

https://codereview.chromium.org/2689273002/diff/1/ui/gfx/canvas.h#newcode297
ui/gfx/canvas.h:297: void DrawSharpLine(const PointF& p1, const PointF& p2,
SkColor color);
On 2017/02/15 00:43:59, Peter Kasting wrote:
> Nit: Is "Sharp" the best name for this?  "DrawIntegralPxLine" maybe?  I can't
> think of anything non-awkward, but when I read "Sharp" I assumed it meant a
> hairline, if I knew what it meant at all.

well, naming is hard. I like Sharp better than IntegralPxLine (which sounds to
me like 1px?) but I think in both cases if I found it in the code I'd need to
resort to looking up the docs to figure out what was going on and why it was
necessary.

I agree it's possible we might want/be able to replace DrawLine with this at
which point we can just rename to DrawLine.

[Evan Stade, 2017-02-15 16:55:04]

estade@chromium.org changed reviewers:
+ msw@chromium.org

[Evan Stade, 2017-02-15 16:55:05]

+msw for owners

[msw, 2017-02-15 21:51:18]

lgtm

[Evan Stade, 2017-02-15 21:58:57]

The CQ bit was checked by estade@chromium.org

[Evan Stade, 2017-02-15 21:58:57]

The patchset sent to the CQ was uploaded after l-g-t-m from
pkasting@chromium.org
Link to the patchset: https://codereview.chromium.org/2689273002/#ps20001
(title: "pkasting review")

[commit-bot: I haz the power, 2017-02-15 22:00:29]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-15 22:37:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-15 22:37:18]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)
  win_clang on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_clang/builds/...)

[Evan Stade, 2017-02-16 03:02:36]

The CQ bit was checked by estade@chromium.org

[commit-bot: I haz the power, 2017-02-16 03:05:19]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-16 04:15:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-02-16 04:15:51]

Try jobs failed on following builders:
  win_chromium_x64_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_x64_...)

[Evan Stade, 2017-02-16 19:09:47]

The CQ bit was checked by estade@chromium.org

[commit-bot: I haz the power, 2017-02-16 19:10:45]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-02-16 21:49:15]

CQ is committing da patch.

Bot data: {"patchset_id": 20001, "attempt_start_ts": 1487272187251920,
"parent_rev": "c82d9e4024d4ada2d0a0677c2ced1f1147dddb7c", "commit_rev":
"7236fb9312cfeb76d7f0c195eb567c995143add5"}

[commit-bot: I haz the power, 2017-02-16 21:50:21]

Description was changed from

==========
Fix appearance of header row separators in table view at fractional
scale factors.

BUG=688507
==========

to

==========
Fix appearance of header row separators in table view at fractional
scale factors.

BUG=688507

Review-Url: https://codereview.chromium.org/2689273002
Cr-Commit-Position: refs/heads/master@{#451107}
Committed:
https://chromium.googlesource.com/chromium/src/+/7236fb9312cfeb76d7f0c195eb56...
==========

[commit-bot: I haz the power, 2017-02-16 21:50:22]

Committed patchset #2 (id:20001) as
https://chromium.googlesource.com/chromium/src/+/7236fb9312cfeb76d7f0c195eb56...