For some (as yet unknown reason) the guard in ConicPathBench that disables the path_hairline_big_AA_conic case isn't working. As an alternate fix, this CL makes the Default path renderer confess its lack of support for conics and allows the Software path renderer to handle non-AA cases. This will work but the real fix is to enable conics in the Default path renderer.
Here is the situation we're seeing in the path_hairline_big_AA_conic case:
the path is a hairline drawn with AA
the render target is multisampled (so AA on the draw gets disabled)
StencilAndCover path renderer doesn't handle hairlines
AAHairLine path renderer only handles AA paths (but can handle conics)
AAConvexPath renderer also only handles AA paths
Default path renderer only handles non-AA paths (but doesn't handle conics)
Software path renderer - was disallowed from handling non-AA paths
BUG=skia:2078
R=bsalomon@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/
418073002
bool antiAlias) const {
// this class can draw any path with any fill but doesn't do any anti-aliasing.
- return !antiAlias &&
+ return !antiAlias && !(SkPath::kConic_SegmentMask & path.getSegmentMasks()) &&
(stroke.isFillStyle() ||
IsStrokeHairlineOrEquivalent(stroke, target->getDrawState().getViewMatrix(), NULL));
}
const SkStrokeRec&,
const GrDrawTarget*,
bool antiAlias) const {
- if (!antiAlias || NULL == fContext) {
- // TODO: We could allow the SW path to also handle non-AA paths but
- // this would mean that GrDefaultPathRenderer would never be called
- // (since it appears after the SW renderer in the path renderer
- // chain). Some testing would need to be done r.e. performance
- // and consistency of the resulting images before removing
- // the "!antiAlias" clause from the above test
+ if (NULL == fContext) {
return false;
}