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
Extended tests (150M+) run to completion in release in about 6 minutes; the standard test suite exceeds 100K and finishes in a few seconds on desktops.
TBR=reed
BUG=skia:3588
Review URL: https://codereview.chromium.org/1037953004
The conic, quadratic and cubic computations were using tolerance^2
instead of tolerance when computing maximum point count, causing paths
to be undertessellated when magnifying and overtessellated when minifying.
(Funny story: this bug went unnoticed back when we were tessellating
paths in screen space, when tolerance and its square were both 1.)
BUG=skia:3731
Review URL: https://codereview.chromium.org/1095773003
Previously the normal/italic style bit was obtained from scanning the
font file. With the new format the style may be stated explicitly, and
this explicit value in the configuration file should override any
information obtained from the font data itself.
This change allows the font element's style attribute to override the
font's style, but retains the default 'auto' setting for backwards
compatibility. Repecting the style bit may become more important with
variation fonts, because it will be up to the configuration writer to
determine what values of the 'slnt' variation should be considered
'normal' or 'italic'.
DOCS_PREVIEW= https://skia.org/?cl=1092093002
Committed: https://skia.googlesource.com/skia/+/673e902c9b9982a167f54f1cc175d8d9cab8bcaf
Review URL: https://codereview.chromium.org/1092093002
Reason for revert:
Failed on the compile bots.
Original issue's description:
> Respect declared font style on Android.
>
> Previously the normal/italic style bit was obtained from scanning the
> font file. With the new format the style may be stated explicitly, and
> this explicit value in the configuration file should override any
> information obtained from the font data itself.
>
> This change allows the font element's style attribute to override the
> font's style, but retains the default 'auto' setting for backwards
> compatibility. Repecting the style bit may become more important with
> variation fonts, because it will be up to the configuration writer to
> determine what values of the 'slnt' variation should be considered
> 'normal' or 'italic'.
>
> DOCS_PREVIEW= https://skia.org/?cl=1092093002
>
> Committed: https://skia.googlesource.com/skia/+/673e902c9b9982a167f54f1cc175d8d9cab8bcafTBR=mtklein@google.com,tomhudson@google.com,scroggo@google.com,bungeman@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1082173004
We only embed images with YUV planes. That should only grab the
subset of color JPEGs supported by PDF.
BUG=skia:3180
Review URL: https://codereview.chromium.org/1025773002
Previously the normal/italic style bit was obtained from scanning the
font file. With the new format the style may be stated explicitly, and
this explicit value in the configuration file should override any
information obtained from the font data itself.
This change allows the font element's style attribute to override the
font's style, but retains the default 'auto' setting for backwards
compatibility. Repecting the style bit may become more important with
variation fonts, because it will be up to the configuration writer to
determine what values of the 'slnt' variation should be considered
'normal' or 'italic'.
DOCS_PREVIEW= https://skia.org/?cl=1092093002
Review URL: https://codereview.chromium.org/1092093002
This algorithm changes the blend math, guarded by SK_LEGACY_COLOR32_MATH. The new math is more correct: it's never off by more than 1, and correct in all the interesting 0x00 and 0xFF edge cases, where the old math was never off by more than 2, and not always correct on the edges.
If you look at tests/BlendTest.cpp, the old code was using the `blend_256_plus1_trunc` algorithm, while the new code uses `blend_256_round_alt`. Neither uses `blend_perfect`, which is about ~35% slower than `blend_256_round_alt`.
This will require an unfathomable number of rebaselines, first to Skia, then to Blink when I remove the guard.
I plan to follow up with some integer SIMD abstractions that can unify these two implementations into a single algorithm. This was originally what I was working on here, but the correctness gains seem to be quite compelling. The only places these two algorithms really differ greatly now is the kernel function, and even there they can really both be expressed abstractly as:
- multiply 8-bits and 8-bits producing 16-bits
- add 16-bits to 16-bits, returning the top 8 bits.
All the constants are the same, except SSE is a little faster to keep 8 16-bit inverse alphas, NEON's a little faster to keep 8 8-bit inverse alphas. I may need to take this small speed win back to unify the two.
We should expect a ~25% speedup on Intel (mostly from unrolling to 8 pixels) and a ~20% speedup on ARM (mostly from using vaddhn to add `color`, round, and narrow back down to 8-bit all into one instruction.
(I am probably missing several more related bugs here.)
BUG=skia:3738,skia:420,chromium:111470
Review URL: https://codereview.chromium.org/1092433002
SkFixedToDouble uses the decimal floating point string representation
of 1/(2^16) to provide a constant value. This value is exactly
representable by a double but the decimal constant currently used
does not map to this value.
This change modifies this constant to more decimal digits so that
the actual double value desired is created.
Review URL: https://codereview.chromium.org/1097473002
Multiple Master fonts often list their weight as 'all'. However, they
usually default to normal weight. State explicitly that we know about
this weight string.
Review URL: https://codereview.chromium.org/1092793002
It's super tedious to keep setting it every time I rerun ./gyp_skia.
Doesn't look like it'll bother the bots.
BUG=skia:
Review URL: https://codereview.chromium.org/1053493005
(We never set arm_version = 7 for iOS...)
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/1092753002
Currently there exist SkScalarPin and SkPin32, and in a future change
another version is desired. This change introduces SkTPin and changes
SkScalarPin and SkPin32 to use it.
Review URL: https://codereview.chromium.org/1090003002
With dashed paths, we get a lot of geometry on the same sort line.
Since the vertices are sorted, it makes more sense to insert edges
from the end (in sort order) than the beginning. This requires
maintaining both the head and tail of the active edge list.
This gives a ~20% perf improvement on tabl_digg.skp.
BUG=skia:3733
Review URL: https://codereview.chromium.org/1089903002
Memory will be overwritten while downsampling some
interlaced gif images, most commonly with odd sizes,
when index of destination row stores in the current
line computed from GifInterlaceIter meets:
X is an integer in [0..height-1]
and
(X < height)
&& ((X - sampleSize/2) % sampleSize == 0)
&& ((X - sampleSize/2)/sampleSize >= height/sampleSize)
Signed-off-by: Lu Tong <lu.x.tong@sonymobile.com>
BUG=skia:
Review URL: https://codereview.chromium.org/1085253002
The dFdy(st.y) computation seems to be better than the dFdx(st.x) computation
on the Mali, so using that. The end result should be about the same.
BUG=skia:3528
Review URL: https://codereview.chromium.org/1082913006
