This method is different from MatrixFilter, in that MatrixFilter does not require a pre-existing
filter, but LocalM does. Also change the comment to be more general, as there is no promise that
we return a different subclass, and certainly not a specific subclass.
This pattern of obj->newWithModifiers() also more closely matches the pattern in SkImage (newSubset).
BUG=skia:
Review URL: https://codereview.chromium.org/1402133002
At draw time, this filter simply concatenates the given matrix to the
CTM, and recurses on its input. The matrix is thus applied to any
upstream filter parameters and crop rects.
BUG=skia:
Review URL: https://codereview.chromium.org/1392833005
Result:
- clients can get a filtered version of an image without having to setup a temp drawing environment
- for some cases, the process is more efficient even than (deprecated) drawSprite, since there is no need to draw/copy the result
Impl:
- made Proxy virtual so we don't need to have an existing device to use it
This, in conjunction with LocalMatrixImageFilter, should allow us to simplify and optimize ApplyImageFilter() in cc/output/gl_renderer.cc
BUG=skia:
Review URL: https://codereview.chromium.org/1390913005
We landed this originally with lazily-correct sequentially-consistent memory
order. It turns out that's regressed performance, we think particularly when
recording paths. We also think there's no need for anything but relaxed memory
order here.
We should see this chart go down if all goes well: https://perf.skia.org/#4329
There are also Chrome performance charts to watch in the linked bug.
BUG=chromium:537700
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-TSAN-Trybot,Test-Ubuntu-GCC-Golo-GPU-GT610-x86_64-Release-TSAN
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1393833003
To further consolidate the various unique owning classes, this bases
SkAutoTUnref on skstd::unique_ptr. Users are updated because of two
breaking changes, swap now takes a reference and reset no longer
returns its argument.
Review URL: https://codereview.chromium.org/1370803002
SkGlyphCache dumps too many glyphs, and to reduce the trace size,
RequestDetails enum is added to SkTraceMemoryDump interface. This
would tell caches to dump only requested details or not a detailed
dump.
BUG=499731
Review URL: https://codereview.chromium.org/1310123007
Reason for revert:
Landed PS8 temporarily to trigger the perf bots.
Original issue's description:
> Implement SkImageFilter::Cache with SkResourceCache.
>
> The single global cache now uses the global SkResourceCache,
> and any Create()ed cache uses a local SkResourceCache.
>
> No real public API changes (and only deletes).
>
> I don't see any pixel diffs on .skps or GMs.
> Don't see any significant perf difference on 8888 or gpu configs.
> DM peak memory usage did drop by about 113M, close to the 128M cache size.
>
> BUG=skia:3662
>
> Landing PS8 temporarily to trigger the perf bots.
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/75135d8ae1aa12e8e6bfce63291e5e876a77546fTBR=reed@google.com,robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3662
Review URL: https://codereview.chromium.org/1381523002
The single global cache now uses the global SkResourceCache,
and any Create()ed cache uses a local SkResourceCache.
No real public API changes (and only deletes).
I don't see any pixel diffs on .skps or GMs.
Don't see any significant perf difference on 8888 or gpu configs.
DM peak memory usage did drop by about 113M, close to the 128M cache size.
BUG=skia:3662
Landing PS8 temporarily to trigger the perf bots.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1370323002
An alternative way of addressing this is to alter SkCanvas::drawRoundRect to just reject isEmpty (i.e., un-sorted or truly empty) input rects.
BUG=skia:3786
Review URL: https://codereview.chromium.org/1373293002
Reason for revert:
Need to somehow get access to encoders in chrome -- link error on the roll since SkImageEncoder is not built as part of chrome.
Original issue's description:
> change pixel-serializer to support reencoding existing data
>
> Trying to evolve this interface so it can
> - support rich set of backend-encoders (including ones like ETC1 that can cheaply convert to KXT
> - allow for encoding images as well as bitmaps (e.g. for picture serialization)
> - perhaps replace SkImageEncoder as an API (assuming we create a factory that returns a serializer given a format)
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/13f48dc85aa68a60da66aaf39c93d527d11d1278TBR=scroggo@google.com,msarett@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1371983003
Trying to evolve this interface so it can
- support rich set of backend-encoders (including ones like ETC1 that can cheaply convert to KXT
- allow for encoding images as well as bitmaps (e.g. for picture serialization)
- perhaps replace SkImageEncoder as an API (assuming we create a factory that returns a serializer given a format)
BUG=skia:
Review URL: https://codereview.chromium.org/1373683003
One side effect is that the SkShader's (or implicit shader's) fragment processor is responsible for the transition from an unpremul paint color to a premul color.
Review URL: https://codereview.chromium.org/1348583002
To avoid breaking existing SKPs, add a deserialization stub which
unflattens SkBitmapSource records to SkImageSources.
R=reed@google.com,mtklein@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1363913002
The Registrar class is unnecessary, as SkFlattenable factory
registration is now handled via initialization routines that can just
call the Register function directly.
Also, no need to lazily initialize gCount to 0, as initializing an int
to a constant value does not require dynamic initialization. (C++
actually guarantees zero initialization of global ints anyway, but
existing practice in Skia appears to favor the explicit "= 0").
Relatedly, this requires removing the unused/unimplemented
SkLayerDrawLooper::MyRegistrar class. And removing that allows Clang
to realize that SkLayerDrawLooper::fTopRec is unneeded too, so remove
that too to squelch the compiler warning/error.
This doesn't change any public API.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1361323002
This implementation improves performance of SkMutex acquire / release pair from 42ns -> 13 ns.
SkSharedMutex and SkSpinlock have the same performance.
It also removes specialized windows and linux/mac code.
BUG=skia:
Review URL: https://codereview.chromium.org/1359733002
Motivation: I want too finalize this API before working on the more
complex problem of adding XMP metadata for PDF/A.
BUG=skia:3110
Review URL: https://codereview.chromium.org/1359943003
This CL removes the uses of SkNEW that have resprouted since commit
385fe4d, and removes the macros entirely now that Android and Chromium
have been cleaned up to no longer depend on them.
A bunch of files implicitly depend on #include <new> from SkPostConfig.h
still though, so keep that for now. To be fixed in a followup CL.
[mtklein mucking around]
Only public API removed.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1360653004
Reason for revert:
Who wants to land forever?
Original issue's description:
> update memset16/32 inlining heuristics
>
> I spent some time looking at perf.skia.org and it looks like we can do better.
>
> It is weird, weird, weird that on x86, we see three completely different behaviors:
> - x86 Android: inlining better for small N, custom better for large N;
> - Windows: inlining better for large N, custom better for small N;
> - other x86: inlining generally better
>
> BUG=skia:4316,chromium:516426
>
> (Temporary, plan to revert.)
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/b68fa409fc00ce2f38e2a0fd6f9dc2379b372481TBR=reed@google.com,jcgregorio@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4316,chromium:516426
Review URL: https://codereview.chromium.org/1358793002
I spent some time looking at perf.skia.org and it looks like we can do better.
It is weird, weird, weird that on x86, we see three completely different behaviors:
- x86 Android: inlining better for small N, custom better for large N;
- Windows: inlining better for large N, custom better for small N;
- other x86: inlining generally better
BUG=skia:4316,chromium:516426
(Temporary, plan to revert.)
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1357193002
Remove some bogus tests on the cache, as they are not thread-reliable. Running w/ discardable these are racy.
BUG=532981
Review URL: https://codereview.chromium.org/1351453004
The new FP is used to implement SkXM::Mode color filters and SkXM::Mode image filters. Also, these now support all advanced SkXM::Mode xfermodes.
Review URL: https://codereview.chromium.org/1334293003
