Track quad type on GrQuad directly
This makes subsequent higher-level drawing APIs more compact, and
shouldn't come with a performance hit. Everywhere we used to need
a GrPerspQuad, we'd also take the GrQuadType as a second argument.
The quad list types already deconstruct the quad so there's no
extra overhead in the op's memory usage.
It also improves usability and decreases the likelihood that an
incorrect quad type is ever associated with the quad.
Bug: skia:
Change-Id: Iba908fb133ad664744a5788a7088d90de0d3a1c2
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/214820
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Michael Ludwig <michaelludwig@google.com>
7 files changed