Move path fallback for AA rect out of SkGpuDevice

Move path fallback for AA rect out of SkGpuDevice

The AA rect batches currently in Skia have view matrix restrictions. If
a view matrix is not supported, we have to draw the rect as a path
instead. This changes moves the decision to draw as a path out of
SkGpuDevice and into GrDrawContext.

BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1551883003

Committed: https://skia.googlesource.com/skia/+/bb53948a127f4bc9272f1583170a1c09a2c7fdd1

[Chris Dalton, 2015-12-30 21:10:01]

Description was changed from

==========
Move path fallback for AA rect out of SkGpuDevice

The AA rect batches currently in Skia have view matrix restrictions. If
a view matrix is not supported, we have to draw the rect as a path
instead. This changes moves the decision to draw as a path out of
SkGpuDevice and into GrDrawContext.

BUG=skia:
==========

to

==========
Move path fallback for AA rect out of SkGpuDevice

The AA rect batches currently in Skia have view matrix restrictions. If
a view matrix is not supported, we have to draw the rect as a path
instead. This changes moves the decision to draw as a path out of
SkGpuDevice and into GrDrawContext.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

[Chris Dalton, 2015-12-30 21:13:44]

cdalton@nvidia.com changed reviewers:
+ bsalomon@google.com, robertphillips@google.com

[bsalomon, 2016-01-04 14:57:58]

bsalomon@google.com changed reviewers:
+ joshualitt@google.com

[bsalomon, 2016-01-04 14:57:58]

Seems like a forward move to me. I'd like Josh to have a look before committing.
In general, these types of decisions should be pushed down into batch factories
as much as possible, but going that far is outside of the scope of what you're
trying to do here.

[joshualitt, 2016-01-04 15:04:25]

On 2016/01/04 14:57:58, bsalomon wrote:
> Seems like a forward move to me. I'd like Josh to have a look before
committing.
> In general, these types of decisions should be pushed down into batch
factories
> as much as possible, but going that far is outside of the scope of what you're
> trying to do here.

I agree with Brian.  LGTM

[Chris Dalton, 2016-01-04 17:33:44]

The CQ bit was checked by cdalton@nvidia.com

[commit-bot: I haz the power, 2016-01-04 17:33:49]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1551883003/1
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1551883003/1

[commit-bot: I haz the power, 2016-01-04 17:48:27]

Description was changed from

==========
Move path fallback for AA rect out of SkGpuDevice

The AA rect batches currently in Skia have view matrix restrictions. If
a view matrix is not supported, we have to draw the rect as a path
instead. This changes moves the decision to draw as a path out of
SkGpuDevice and into GrDrawContext.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...
==========

to

==========
Move path fallback for AA rect out of SkGpuDevice

The AA rect batches currently in Skia have view matrix restrictions. If
a view matrix is not supported, we have to draw the rect as a path
instead. This changes moves the decision to draw as a path out of
SkGpuDevice and into GrDrawContext.

BUG=skia:
GOLD_TRYBOT_URL=
https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&is...

Committed:
https://skia.googlesource.com/skia/+/bb53948a127f4bc9272f1583170a1c09a2c7fdd1
==========

[commit-bot: I haz the power, 2016-01-04 17:48:28]

Committed patchset #1 (id:1) as
https://skia.googlesource.com/skia/+/bb53948a127f4bc9272f1583170a1c09a2c7fdd1

[f(malita), 2016-01-04 20:38:48]

On 2016/01/04 17:48:28, commit-bot: I haz the power wrote:
> Committed patchset #1 (id:1) as
> https://skia.googlesource.com/skia/+/bb53948a127f4bc9272f1583170a1c09a2c7fdd1

Looks like this is causing one minor layout test diff (and blocking the roll):
https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/...

Is the diff expected?

[bsalomon, 2016-01-04 20:43:53]

On 2016/01/04 20:38:48, f(malita) wrote:
> On 2016/01/04 17:48:28, commit-bot: I haz the power wrote:
> > Committed patchset #1 (id:1) as
> >
https://skia.googlesource.com/skia/+/bb53948a127f4bc9272f1583170a1c09a2c7fdd1
> 
> Looks like this is causing one minor layout test diff (and blocking the roll):
>
https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/...
> 
> Is the diff expected?

Yes it is expected. The old code over-zealously sent rotated rects through path
rendering code, the new code draws them as rects.

[f(malita), 2016-01-04 20:45:32]

On 2016/01/04 20:43:53, bsalomon wrote:
> On 2016/01/04 20:38:48, f(malita) wrote:
> > On 2016/01/04 17:48:28, commit-bot: I haz the power wrote:
> > > Committed patchset #1 (id:1) as
> > >
> https://skia.googlesource.com/skia/+/bb53948a127f4bc9272f1583170a1c09a2c7fdd1
> > 
> > Looks like this is causing one minor layout test diff (and blocking the
roll):
> >
>
https://storage.googleapis.com/chromium-layout-test-archives/linux_blink_rel/...
> > 
> > Is the diff expected?
> 
> Yes it is expected. The old code over-zealously sent rotated rects through
path
> rendering code, the new code draws them as rects.

Thanks.  I'll land a manual roll + rebaseline then.