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
This moves the SkFontMgr::Factory implementation which creates a
FontMgr around FontConfig into its own file, and allows the user
to create one manually.
Review URL: https://codereview.chromium.org/1189753007
- Use SkAtomic<int32_t> for pending work count so we're statically
forced to operate on it with atomic methods.
- Replacing old methods like sk_atomic_inc/dec gives us finer control
over which barriers we need for each operation.
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1193493003
This CL makes the GrTextContext be owned (and hidden) by the GrDrawContext. This funnels all the drawText* calls through the GrDrawContext and hides the (dispreferred) GrPipelineBuilder drawText variant.
Some consequences of this are:
GrDrawContext now has to get the text drawing settings (i.e., SkDeviceProperties & useDFT). This means that we need a separate GrDrawContext for each combination of pixel geometry and DFT-use.
All the GrTextContext-derived classes now get a back pointer to the originating GrDrawContext so their method calls no longer take one.
Committed: https://skia.googlesource.com/skia/+/5b16e740fe6ab6d679083d06f07651602265081b
Review URL: https://codereview.chromium.org/1175553002
Reason for revert:
Breaking Test-Win8-MSVC-ShuttleA-GPU-GTX660-x86_64-Debug ?
https://build.chromium.org/p/client.skia/builders/Test-Win8-MSVC-ShuttleA-GPU-GTX660-x86_64-Debug/builds/436/steps/dm/logs/stdio
Original issue's description:
> Make GrTextContext be owned by the GrDrawContext
>
> This CL makes the GrTextContext be owned (and hidden) by the GrDrawContext. This funnels all the drawText* calls through the GrDrawContext and hides the (dispreferred) GrPipelineBuilder drawText variant.
>
> Some consequences of this are:
>
> GrDrawContext now has to get the text drawing settings (i.e., SkDeviceProperties & useDFT). This means that we need a separate GrDrawContext for each combination of pixel geometry and DFT-use.
>
> All the GrTextContext-derived classes now get a back pointer to the originating GrDrawContext so their method calls no longer take one.
>
> Committed: https://skia.googlesource.com/skia/+/5b16e740fe6ab6d679083d06f07651602265081bTBR=joshualitt@chromium.org,joshualitt@google.com,jvanverth@google.com,reed@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/1178383003
This CL makes the GrTextContext be owned (and hidden) by the GrDrawContext. This funnels all the drawText* calls through the GrDrawContext and hides the (dispreferred) GrPipelineBuilder drawText variant.
Some consequences of this are:
GrDrawContext now has to get the text drawing settings (i.e., SkDeviceProperties & useDFT). This means that we need a separate GrDrawContext for each combination of pixel geometry and DFT-use.
All the GrTextContext-derived classes now get a back pointer to the originating GrDrawContext so their method calls no longer take one.
Review URL: https://codereview.chromium.org/1175553002
Make visualbench and SampleApp build in CONSOLE mode so that we can see stdout.
I verified that by undoing the gyp modifications both tools will build as GUI.
Review URL: https://codereview.chromium.org/1185303004
Let's make CPU-bound .SKP benching mimic Chrome's tiles.
Unfortunately, the CPU code also performs a lot better with those big wide tiles...
BUG=skia:
Review URL: https://codereview.chromium.org/1189863002
This is hopefully a temporary fix. It's unclear why distance fields
are so much slower on the N4 (and N7).
BUG=chromium:467569
Review URL: https://codereview.chromium.org/1184153004
