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
This makes the blurcircles bench go from ~33us to ~8us on Windows desktop.
It will require layout test suppressions
Review URL: https://codereview.chromium.org/1311583005
Possible follow-up changes to consider
1. Roll SkImage_Raster and _Gpu into _Generator, where the generator (or cacherator) is backed by a pre-existing texture or raster.
2. Evolve SkImageUsageType into a verb requiring stretching, and have the caller (common code) digest the caps() and usage, so that subclasses are just told what to do (stretch or not)
3. Common code/utility to convert an unstretched texture into a stretch one (and cache it) if the generator can only make an unstretched one.
BUG=skia:
Review URL: https://codereview.chromium.org/1282363002
This was a pre-SkOpts attempt that we can bring under its wing now.
This should be a perf no-op, deo volente.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1314863006
SkOncePtr<T[]> is identical to SkOncePtr<T> except we'll default to delete[]
for cleanup.
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1311893010
Reason for revert:
Breaks Chrome roll.
obj/skia/ext/skia_chrome.skia_memory_dump_provider.o
does not have -I include/private on its include path, but transitively includes SkMessageBus.h.
Original issue's description:
> Port uses of SkLazyPtr to SkOncePtr.
>
> This gives SkOncePtr a non-trivial destructor that uses std::default_delete
> by default. This is overrideable, as seen in SkColorTable.
>
> SK_DECLARE_STATIC_ONCE_PTR still just leaves its pointers hanging at EOP.
>
> BUG=skia:
>
> No public API changes.
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/a1254acdb344174e761f5061c820559dab64a74cTBR=herb@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1334523002
This gives SkOncePtr a non-trivial destructor that uses std::default_delete
by default. This is overrideable, as seen in SkColorTable.
SK_DECLARE_STATIC_ONCE_PTR still just leaves its pointers hanging at EOP.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1322933005
