The regression occurred when we dropped the maximum DF size from 192
to 162, which meant that any glyph > 324 ended up being rendered as paths
rather than the previous > 384. This pushes the threshold for
rendering paths up to 384. Quality looks fine on high-res devices
which is why this is restricted to Android-only (low-res Android devices
should only rarely have text that large).
BUG=chromium:467569
Committed: https://skia.googlesource.com/skia/+/932d413e69845989fadaecf5bcb8686ec8c05032
Review URL: https://codereview.chromium.org/1183053005
sk_inv_determinant has a guard that the determinant can't get too big so this CL only checks if the determinant gets too small.
BUG=492263
Review URL: https://codereview.chromium.org/1188433011
The SkFaceRec class is some data which needs to remain alive for the
life of an FT_Face. ref_ft_face returns SkFaceRec, but confusingly
unref_ft_face takes an FT_Face. Since no one was using the SkFaceRec
for anything other than accessing the FT_Face, have ref_ft_face
return FT_Face instead and remove the unused SkFaceRec pointer from
the scaler context.
Review URL: https://codereview.chromium.org/1180223005
The regression occurred when we dropped the maximum DF size from 192
to 162, which meant that any glyph > 324 ended up being rendered as paths
rather than the previous > 384. This pushes the threshold for
rendering paths up to 384. Quality looks fine on high-res devices
which is why this is restricted to Android-only (low-res Android devices
should only rarely have text that large).
BUG=chromium:467569
Review URL: https://codereview.chromium.org/1183053005
Based on SkImageDecoder_libwebp.
TODO:
Support YUV? (Longer term - may influence our API for SkImageGenerator)
BUG=skia:3257
Review URL: https://codereview.chromium.org/1044433002
Updates GrGLProgram to tell the gpu object which textures it wants
bound, instead of calling bindTexture directly. This begins to break
its dependence on the specific GrGLGpu object.
BUG=skia:
Review URL: https://codereview.chromium.org/1192463003
The intent was to define FT_HAS_COLOR when building with a pre
2.5.1 version of FreeType for forward compatibility. However,
the definition here is wrong and also never used.
Review URL: https://codereview.chromium.org/1178943009
This file had one declaration in it which actually affected the
SkFontMgr and had nothing to do with typefaces specifically. As a
result, the declaration was moved to SkFontMgr_android.h. Now that
the users have been updated, remove this now unused file.
Review URL: https://codereview.chromium.org/1177173004
When calling SkRegion::writeToMemory(NULL), it should return the same
number of bytes that it writes when calling
SkRegion::writeToMemory(buffer). Add a test to confirm this.
BUG=b/21271229
Review URL: https://codereview.chromium.org/1188293002
This should be a drop-in replacement for most for-loops to make them run in parallel:
for (int i = 0; i < N; i++) { code... }
~~~>
sk_parallel_for(N, [&](int i) { code... });
This is just syntax sugar over SkTaskGroup to make this use case really easy to write.
There's no more overhead that we weren't already forced to add using an interface like batch(),
and no extra heap allocations.
I've replaced 3 uses of SkTaskGroup with sk_parallel_for:
1) My unit tests for SkOnce.
2) Cary's path fuzzer.
3) SkMultiPictureDraw.
Performance should be the same. Please compare left and right for readability. :)
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1184373003
Reason for revert:
Seeing some Nexus 4 perf regressions in individual tests in Chromium that may be due to this change. This doesn't appear to be the correct fix for the bug in any case.
Original issue's description:
> Bump up point where we switch to distance fields for large glyphs
>
> This is hopefully a temporary fix. It's unclear why distance fields
> are so much slower on the N4 (and N7).
>
> BUG=chromium:467569
>
> Committed: https://skia.googlesource.com/skia/+/0fce1fb02d93e66d42528f322f8aa4ca64ff0fb2TBR=joshualitt@google.com,bsalomon@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=chromium:467569
Review URL: https://codereview.chromium.org/1178713005
Turns out _LIFO does work as we expected, keeping N < M threads active when we
have M live threads but only N units of work to do at a time. Also as we
expected _FIFO does round-robin through the threads.
Performance doesn't seem to be affected, but let's do it anyway.
If nothing else this makes profiles a little easier to read.
I don't see POSIX or Windows equivalents.
BUG=skia:
Review URL: https://codereview.chromium.org/1192433006
This allows a faster implementation of our SkTaskGroup thread pool.
It also means we don't need SkCondVar (which, remember, isn't supported on XP.)
Doing some testing with SampleApp, this really cuts down on the overhead from SkTaskGroup, e.g. 30% to 10%.
BUG=skia:
Review URL: https://codereview.chromium.org/1192573003
I think these changes to the subset benchmarks cover what we discussed yesterday.
I removed the divisor benchmarks (2x2, 3x3) and changed the single subset benchmarks.
Also, we will no longer benchmark subset decodes on small images.
BUG=skia:
Review URL: https://codereview.chromium.org/1188223002
