The stencil-and-cover and tessellating path renderers currently
tessellate curves to linear segments to within one screen space pixel.
This is fairly poor accuracy, as can be seen from the strokecircle GM:
there are noticeable rotating bumps on the circles.
Improving the tolerance to 0.25 pixel eliminates the bumps, and
approximates the 16x supersampling of the raster path.
This does have a performance hit: 3-6% on desktop on
the IE chalkboard demo, ~1% on Nexus 7 2013.
Note: this will require rebaselining a number of GPU and MSAA images
in Skia, but nothing in Chrome (yet).
BUG=skia:3731
Review URL: https://codereview.chromium.org/1072273007
Also adds glBlendEquation, which the extension interacts with, to the
core of GrGLInterface. Validation of this function is temporarily
disabled until Chrome hooks it up.
BUG=skia:
Review URL: https://codereview.chromium.org/1039693004
Chrome wants to call this more often, and it's quite slow today.
Seems like this could be clearer if SkPictureUtils::ApproxBytesUsed() were SkPicture::approxBytesUsed().
BUG=chromium:471873
Review URL: https://codereview.chromium.org/1090943004
This requires we remove NVPR from the default set of configs, as we only find
out at runtime that it's not available. All the other defaults will either be
compiled in and supported, or not compiled in and non-fatally skipped as
unknown configs.
BUG=skia:
Review URL: https://codereview.chromium.org/1100773003
Reason for revert:
Xfermode_SrcOver not looking encouraging. Up to 50% regressions.
https://perf.skia.org/#3242
Original issue's description:
> Convert Color32 code to perfect blend.
>
> Before we commit to blend_256_round_alt, let's make sure blend_perfect is
> really slower in practice (i.e. regresses on perf.skia.org).
>
> blend_perfect is really the most desirable algorithm if we can afford it. Not
> only is it correct, but it's easy to think about and break into correct pieces:
> for instance, its div255() doesn't require any coordination with the multiply.
>
> This looks like a 30% hit according to microbenches. That said, microbenches
> said my previous change would be a 20-25% perf improvement, but it didn't end
> up showing a significant effect at a high level.
>
> As for correctness, I see a bunch of off-by-1 compared to blend_256_round_alt
> (exactly what we'd expect), and one off-by-3 in a GM that looks like it has a
> bunch of overdraw.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/61221e7f87a99765b0e034020e06bb018e2a08c2TBR=reed@google.com,fmalita@chromium.org,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1083923006
More nullptr checks for factories I have added.
Other checks more Yoda-like I have made. (Skia style this is.)
BUG=skia:
Review URL: https://codereview.chromium.org/1086393004
This makes all non-XMLCALL element_handler functions uniform by making
their signature
void XXX_element_handler(FamilyData* self, const char** attributes)
This makes the code somewhat easier to follow, as it makes explicit
which functions are actually logically methods of FamilyData (start
with 'FamilyData* self') and which are called directly by expat
(start with 'void* data').
Review URL: https://codereview.chromium.org/1086943007
Before we were returning non transformed bounds for the ovals instead of
device bounds from the various draw calls. This was causing us to do dst
copies from the wrong portion of the screen when there was some transform
on the matrix.
This fixes the gpu issues from the new imagefilters-xfermodes gm as well an
old bug from the srcmode GM.
BUG=skia:
Review URL: https://codereview.chromium.org/1090453003
The Android font parser prints a number of helpful messages when
something seems amiss in the configuration file. Give all of these
messages a common and more informative format.
Review URL: https://codereview.chromium.org/1096063003
Before we commit to blend_256_round_alt, let's make sure blend_perfect is
really slower in practice (i.e. regresses on perf.skia.org).
blend_perfect is really the most desirable algorithm if we can afford it. Not
only is it correct, but it's easy to think about and break into correct pieces:
for instance, its div255() doesn't require any coordination with the multiply.
This looks like a 30% hit according to microbenches. That said, microbenches
said my previous change would be a 20-25% perf improvement, but it didn't end
up showing a significant effect at a high level.
As for correctness, I see a bunch of off-by-1 compared to blend_256_round_alt
(exactly what we'd expect), and one off-by-3 in a GM that looks like it has a
bunch of overdraw.
BUG=skia:
Review URL: https://codereview.chromium.org/1098913002
