Proper rendering of stacked tabs for MD.

Proper rendering of stacked tabs for MD.

When stacking tabs in MD, we now draw the fill and stroke separately, drawing the fill completely but clipping the stroke against the neighboring tab's stroke.  Drawing the fill without this clipping allows the fill to underlay the overlapped tab's stroke, while clipping the stroke prevents unsightly overdraw.  To prevent this from being excessively inefficient, we only use this two-image technique when we might actually be clipping one tab against another (see subsequent paragraphs).

This also changes tab and close button hit-testing to use more precise masks in the case of stacked tabs.  Previously, when not stacking, we'd use hit-test regions the same shape as the tab, but when stacking, we'd switch to less-accurate rectangular regions.  We now use precise masks in both cases, with the difference being that when not stacking, the hit region for a tab "behind" another tab is still shaped like the full tab, while when stacking, that hit region is actually clipped by the tab that's "on top".  It's not clear to me how this affects touch hit-testing.  It seems like we don't really need/want the stacked and not-stacked cases to differ here.  I kind of think we want to clip in both cases, which would unify the behavior and perhaps simplify the code, but I'm not sure.  There is a comment in about this.

Tab close buttons work similarly: we now intersect the close button's square mask with its parent tab's mask, so when stacking, the close buttons are clipped by overlaid tabs.  Per a TODO in the code, I removed the existing code that made the tab close button entirely un-hittable in this case.  Once again, I left a comment asking precisely what the effect of these shape changes on touch targeting is.  Note that it's not convenient to clip the close button masks like this without also clipping the tab masks themselves as in the above paragraph; one depends on the other.

BUG=609022
TEST=Trigger stacked tabs mode, stack some tabs, and ensure the top strokes don't visible overlap (and make a darker stroke)

Committed: https://crrev.com/59ea4a04aa8b4db5e7413761864902570601e309
Cr-Commit-Position: refs/heads/master@{#411197}

[Peter Kasting, 2016-08-04 00:38:38]

Description was changed from

==========
Stacked tabs cleanup

BUG=
==========

to

==========
Proper rendering of stacked tabs for MD.

When stacking tabs in MD, we now draw the fill and stroke separately, drawing
the fill completely but clipping the stroke against the neighboring tab's
stroke.  Drawing the fill without this clipping allows the fill to underlay the
overlapped tab's stroke, while clipping the stroke prevents unsightly overdraw. 
To prevent this from being excessively inefficient, we only use this two-image
technique when we might actually be clipping one tab against another (see
subsequent paragraphs).

This also changes tab and close button hit-testing to use more precise masks in
the case of stacked tabs.  Previously, when not stacking, we'd use hit-test
regions the same shape as the tab, but when stacking, we'd switch to
less-accurate rectangular regions.  We now use precise masks in both cases, with
the difference being that when not stacking, the hit region for a tab "behind"
another tab is still shaped like the full tab, while when stacking, that hit
region is actually clipped by the tab that's "on top".  It's not clear to me how
this affects touch hit-testing.  It seems like we don't really need/want the
stacked and not-stacked cases to differ here.  I kind of think we want to clip
in both cases, which would unify the behavior and perhaps simplify the code, but
I'm not sure.  There is a comment in about this.

Tab close buttons work similarly: we now intersect the close button's square
mask with its parent tab's mask, so when stacking, the close buttons are clipped
by overlaid tabs.  Per a TODO in the code, I removed the existing code that made
the tab close button entirely un-hittable in this case.  Once again, I left a
comment asking precisely what the effect of these shape changes on touch
targeting is.  Note that it's not convenient to clip the close button masks like
this without also clipping the tab masks themselves as in the above paragraph;
one depends on the other.

BUG=609022
TEST=Trigger stacked tabs mode, stack some tabs, and ensure the top strokes
don't visible overlap (and make a darker stroke)
==========

[Peter Kasting, 2016-08-04 00:38:38]

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

[Peter Kasting, 2016-08-04 00:41:31]

This basically works, but I have some questions about the inconsistency of how
we're generating the masks here.  See CL description and TODOs in the code.

[Peter Kasting, 2016-08-04 00:41:45]

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

[commit-bot: I haz the power, 2016-08-04 00:42:31]

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, 2016-08-04 00:54:17]

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

[commit-bot: I haz the power, 2016-08-04 00:54:18]

Dry run: Try jobs failed on following builders:
  chromeos_amd64-generic_chromium_compile_only_ng on
master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_amd64-...)
  chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux
(JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/chromeos_daisy_...)

[sky, 2016-08-04 16:48:00]

I wanted to try this out and ponder it, but I get compile errors:
d:\src\builds\build2\src\chrome\browser\ui\views\tabs\tab.cc(1488): error C2660:
'`anonymous-namespace'::GetFillPath': function does not take 3 arguments

Is there another patch that needs to land first?

[Peter Kasting, 2016-08-04 21:24:02]

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

[Peter Kasting, 2016-08-04 21:24:02]

On 2016/08/04 16:48:00, sky wrote:
> I wanted to try this out and ponder it, but I get compile errors:
> d:\src\builds\build2\src\chrome\browser\ui\views\tabs\tab.cc(1488): error
C2660:
> '`anonymous-namespace'::GetFillPath': function does not take 3 arguments
> 
> Is there another patch that needs to land first?

No, I just screwed it up.  Try again.

[sky, 2016-08-04 23:42:09]

LGTM and I didn't notice any oddities. Seems to me we should clip in both cases
too.

https://codereview.chromium.org/2210033002/diff/20001/chrome/browser/ui/views...
File chrome/browser/ui/views/tabs/tab.cc (right):

https://codereview.chromium.org/2210033002/diff/20001/chrome/browser/ui/views...
chrome/browser/ui/views/tabs/tab.cc:994: auto border_getter =
base::Bind(&GetBorderPath, scale, true, extend_to_top);
tricky

[Peter Kasting, 2016-08-05 00:52:00]

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

[Peter Kasting, 2016-08-05 00:52:00]

Terry, do you happen to know whether touch targeting will be affected
(presumably, made more accurate) by the places I've added TODOs about in this
CL?  Specifically, in some cases the hit region for a tab or tab close button is
clipped by a tab that occludes it, and in some cases it's not.  Given the code
in tab_strip.cc that tries to choose the right tab for an event, I'm not sure
whether all this is pointless and we should never do it, or it's helpful and we
should always do it (even in not-stacked-tabs mode), or what.

I can check in as-is, and we won't really change the cases we're clipping (just
make the clipping more accurate than it is today), but the state of the world
seems very strange.

[Peter Kasting, 2016-08-08 22:50:49]

Terry: try the current patch set, which rips out the masking entirely.

[tdanderson, 2016-08-09 22:57:09]

On 2016/08/08 22:50:49, Peter Kasting wrote:
> Terry: try the current patch set, which rips out the masking entirely.

Peter, do you mind rebasing against current ToT and re-uploading?
I am having some trouble applying this locally.

[Peter Kasting, 2016-08-10 00:16:36]

Try it now.

[tdanderson, 2016-08-10 12:44:16]

On 2016/08/10 00:16:36, Peter Kasting wrote:
> Try it now.

Touch hit-testing of stacked tabs on CrOS feels fine to me with
Patch Set 4 (if anything, it feels like an improvement).

[Peter Kasting, 2016-08-10 21:14:17]

The CQ bit was checked by pkasting@chromium.org

[Peter Kasting, 2016-08-10 21:14:18]

The patchset sent to the CQ was uploaded after l-g-t-m from sky@chromium.org
Link to the patchset: https://codereview.chromium.org/2210033002/#ps80001
(title: "Resync")

[commit-bot: I haz the power, 2016-08-10 21:15:06]

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, 2016-08-10 22:48:34]

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

[commit-bot: I haz the power, 2016-08-10 22:48:35]

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_...)

[Peter Kasting, 2016-08-10 23:31:44]

The CQ bit was checked by pkasting@chromium.org

[commit-bot: I haz the power, 2016-08-10 23:33:36]

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, 2016-08-11 00:14:37]

Description was changed from

==========
Proper rendering of stacked tabs for MD.

When stacking tabs in MD, we now draw the fill and stroke separately, drawing
the fill completely but clipping the stroke against the neighboring tab's
stroke.  Drawing the fill without this clipping allows the fill to underlay the
overlapped tab's stroke, while clipping the stroke prevents unsightly overdraw. 
To prevent this from being excessively inefficient, we only use this two-image
technique when we might actually be clipping one tab against another (see
subsequent paragraphs).

This also changes tab and close button hit-testing to use more precise masks in
the case of stacked tabs.  Previously, when not stacking, we'd use hit-test
regions the same shape as the tab, but when stacking, we'd switch to
less-accurate rectangular regions.  We now use precise masks in both cases, with
the difference being that when not stacking, the hit region for a tab "behind"
another tab is still shaped like the full tab, while when stacking, that hit
region is actually clipped by the tab that's "on top".  It's not clear to me how
this affects touch hit-testing.  It seems like we don't really need/want the
stacked and not-stacked cases to differ here.  I kind of think we want to clip
in both cases, which would unify the behavior and perhaps simplify the code, but
I'm not sure.  There is a comment in about this.

Tab close buttons work similarly: we now intersect the close button's square
mask with its parent tab's mask, so when stacking, the close buttons are clipped
by overlaid tabs.  Per a TODO in the code, I removed the existing code that made
the tab close button entirely un-hittable in this case.  Once again, I left a
comment asking precisely what the effect of these shape changes on touch
targeting is.  Note that it's not convenient to clip the close button masks like
this without also clipping the tab masks themselves as in the above paragraph;
one depends on the other.

BUG=609022
TEST=Trigger stacked tabs mode, stack some tabs, and ensure the top strokes
don't visible overlap (and make a darker stroke)
==========

to

==========
Proper rendering of stacked tabs for MD.

When stacking tabs in MD, we now draw the fill and stroke separately, drawing
the fill completely but clipping the stroke against the neighboring tab's
stroke.  Drawing the fill without this clipping allows the fill to underlay the
overlapped tab's stroke, while clipping the stroke prevents unsightly overdraw. 
To prevent this from being excessively inefficient, we only use this two-image
technique when we might actually be clipping one tab against another (see
subsequent paragraphs).

This also changes tab and close button hit-testing to use more precise masks in
the case of stacked tabs.  Previously, when not stacking, we'd use hit-test
regions the same shape as the tab, but when stacking, we'd switch to
less-accurate rectangular regions.  We now use precise masks in both cases, with
the difference being that when not stacking, the hit region for a tab "behind"
another tab is still shaped like the full tab, while when stacking, that hit
region is actually clipped by the tab that's "on top".  It's not clear to me how
this affects touch hit-testing.  It seems like we don't really need/want the
stacked and not-stacked cases to differ here.  I kind of think we want to clip
in both cases, which would unify the behavior and perhaps simplify the code, but
I'm not sure.  There is a comment in about this.

Tab close buttons work similarly: we now intersect the close button's square
mask with its parent tab's mask, so when stacking, the close buttons are clipped
by overlaid tabs.  Per a TODO in the code, I removed the existing code that made
the tab close button entirely un-hittable in this case.  Once again, I left a
comment asking precisely what the effect of these shape changes on touch
targeting is.  Note that it's not convenient to clip the close button masks like
this without also clipping the tab masks themselves as in the above paragraph;
one depends on the other.

BUG=609022
TEST=Trigger stacked tabs mode, stack some tabs, and ensure the top strokes
don't visible overlap (and make a darker stroke)
==========

[commit-bot: I haz the power, 2016-08-11 00:14:38]

Committed patchset #5 (id:80001)

[commit-bot: I haz the power, 2016-08-11 00:16:52]

Description was changed from

==========
Proper rendering of stacked tabs for MD.

When stacking tabs in MD, we now draw the fill and stroke separately, drawing
the fill completely but clipping the stroke against the neighboring tab's
stroke.  Drawing the fill without this clipping allows the fill to underlay the
overlapped tab's stroke, while clipping the stroke prevents unsightly overdraw. 
To prevent this from being excessively inefficient, we only use this two-image
technique when we might actually be clipping one tab against another (see
subsequent paragraphs).

This also changes tab and close button hit-testing to use more precise masks in
the case of stacked tabs.  Previously, when not stacking, we'd use hit-test
regions the same shape as the tab, but when stacking, we'd switch to
less-accurate rectangular regions.  We now use precise masks in both cases, with
the difference being that when not stacking, the hit region for a tab "behind"
another tab is still shaped like the full tab, while when stacking, that hit
region is actually clipped by the tab that's "on top".  It's not clear to me how
this affects touch hit-testing.  It seems like we don't really need/want the
stacked and not-stacked cases to differ here.  I kind of think we want to clip
in both cases, which would unify the behavior and perhaps simplify the code, but
I'm not sure.  There is a comment in about this.

Tab close buttons work similarly: we now intersect the close button's square
mask with its parent tab's mask, so when stacking, the close buttons are clipped
by overlaid tabs.  Per a TODO in the code, I removed the existing code that made
the tab close button entirely un-hittable in this case.  Once again, I left a
comment asking precisely what the effect of these shape changes on touch
targeting is.  Note that it's not convenient to clip the close button masks like
this without also clipping the tab masks themselves as in the above paragraph;
one depends on the other.

BUG=609022
TEST=Trigger stacked tabs mode, stack some tabs, and ensure the top strokes
don't visible overlap (and make a darker stroke)
==========

to

==========
Proper rendering of stacked tabs for MD.

When stacking tabs in MD, we now draw the fill and stroke separately, drawing
the fill completely but clipping the stroke against the neighboring tab's
stroke.  Drawing the fill without this clipping allows the fill to underlay the
overlapped tab's stroke, while clipping the stroke prevents unsightly overdraw. 
To prevent this from being excessively inefficient, we only use this two-image
technique when we might actually be clipping one tab against another (see
subsequent paragraphs).

This also changes tab and close button hit-testing to use more precise masks in
the case of stacked tabs.  Previously, when not stacking, we'd use hit-test
regions the same shape as the tab, but when stacking, we'd switch to
less-accurate rectangular regions.  We now use precise masks in both cases, with
the difference being that when not stacking, the hit region for a tab "behind"
another tab is still shaped like the full tab, while when stacking, that hit
region is actually clipped by the tab that's "on top".  It's not clear to me how
this affects touch hit-testing.  It seems like we don't really need/want the
stacked and not-stacked cases to differ here.  I kind of think we want to clip
in both cases, which would unify the behavior and perhaps simplify the code, but
I'm not sure.  There is a comment in about this.

Tab close buttons work similarly: we now intersect the close button's square
mask with its parent tab's mask, so when stacking, the close buttons are clipped
by overlaid tabs.  Per a TODO in the code, I removed the existing code that made
the tab close button entirely un-hittable in this case.  Once again, I left a
comment asking precisely what the effect of these shape changes on touch
targeting is.  Note that it's not convenient to clip the close button masks like
this without also clipping the tab masks themselves as in the above paragraph;
one depends on the other.

BUG=609022
TEST=Trigger stacked tabs mode, stack some tabs, and ensure the top strokes
don't visible overlap (and make a darker stroke)

Committed: https://crrev.com/59ea4a04aa8b4db5e7413761864902570601e309
Cr-Commit-Position: refs/heads/master@{#411197}
==========

[commit-bot: I haz the power, 2016-08-11 00:16:53]

Patchset 5 (id:??) landed as
https://crrev.com/59ea4a04aa8b4db5e7413761864902570601e309
Cr-Commit-Position: refs/heads/master@{#411197}