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
If a path contains a moveTo followed by a line or curve,
even if the line or curve has no length, SVG expects
the end caps to draw if the cap style is round or square.
Fredrik Söderquist attached a patch to the chrome bug
(slightly modified here) that fixes layout test failures
resulting from deleting special-case code in SVG
dealing with zero-length path segments.
R=reed@google.com,fs@opera.com
BUG=22974
Review URL: https://codereview.chromium.org/1330623003
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
Image encoding may fail during serialization, resulting in zero-length
encoded data in the SKP.
Instead of invalidating the stream (and preventing deserialization of
the whole picture) we can instantiate placeholder images.
BUG=skia:4285
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1308273011
crbug.com/526025 includes a minimized SVG test case.
Translating that test case into native code (fuzzTNG)
did not reproduce the bug. That test case should
have not been included with skia issue 1323813003,
and is deleted here.
Running the minimal test case in a modified version
of chrome isolated the bug. The modified version
generated the test fuzz763_3 with the edit
#define DEBUGGING_PATHOPS_FROM_HOST 1
in src/pathops/SkPathopsOp.cpp line 188.
Rename fuzz763_3 to issue_526025 to associate the test
with the bug. Note that the bug contains the body of the
CL in comment $5.
R=reed@google.com
Review URL: https://codereview.chromium.org/1315503005
This switches over SkXfermodes_opts.h and SkColorMatrixFilter to use Sk4f,
and converts the SkPMFloat benches to Sk4f benches.
No pixels should change here, and no code beyond the Sk4f_ benches should change speed.
The benches are faster than the old versions.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1324743002
The list of intersection points on a curve segment may have
entries that can be safely removed when nearby points have
nearly the same t value and point value. When a path includes
very large curves as well as small ones, as is the case with
this fuzzer, additional points may lie between the similar
points that do not meet the nearby criteria.
After merging the nearby point with its doppelganger,
SkOpSegment::moveNearby() unnecessarily set the doppelganger's
next pointer to the one following the nearby point. While
this usually has no effect, since the merge already updated
the linked list, the explicit call removes the additional
outlier points from the segment.
TBR=reed@google.com
BUG=526025
Review URL: https://codereview.chromium.org/1323813003
The million SKPs generated require >5T of storage. A good deal
of that are copies of system fonts.
Chrome built with
#DEFINE SK_WHITELIST_SERIALIZED_TYPEFACES
will omit the font data if the font matches a precomputed
checksum.
The captured SKP prepends sk_ to the names of fonts that
have their data omitted. The SKP consumer can either add
renamed fonts from the recording machine, or add
gDeserializeTypefaceDelegate = WhitelistDeserializeTypeface;
which strips the sk_ prefix when deserializing typefaces.
whitelist_typefaces --check
Computes the checksums of fallback
fonts and returns 0 if the checksums match the checked-in
file SkWhitelistChecksum.cpp.
whitelist_typefaces --generate
Writes an updated version of SkWhitelistChecksum.cpp.
(Added Mike since this modifies a public header)
R=bungeman@google.com,rmistry@google.com,reed@google.com
Review URL: https://codereview.chromium.org/1317913005
Redesigns SkScanlineDecoder.h to indicate the ordering
in which the scanlines are provided
Refactors SkSwizzler::Fill() to include the zeroInit check
and to actually be correct.
BUG=skia:3257
BUG=skia:4198
Review URL: https://codereview.chromium.org/1287423002
This macro was responsible for producing code like:
static SkAlignedStorage<sizeof(Foo)> g_gFoo_Storage;
static Foo* gFoo = new(g_gFoo_Storage.get()) Foo;
static SkAutoTDestroy<Foo> gFoo_ad(gFoo);
which would allocate static storage for an object of type Foo
(g_gFoo_Storage), lazily instantiate the object in that memory (via
gFoo's initializer), and then ensure that at global destruction time
the object is destroyed (via gFoo_Ad's destructor).
However, the exact same effect is achieved by just writing:
static Foo gFoo;
Review URL: https://codereview.chromium.org/1314763009
Unfortunately, immintrin.h (which is also included by SkTypes)
includes xmmintrin.h which includes mm_malloc.h which includes
stdlib.h for malloc even though, from the implementation, it is
difficult to see why.
Fortunately, arm_neon.h does not seem to be involved in such
shenanigans, so building for Android will keep things sane.
TBR=reed@google.com
Doesn't change Skia API, just moves an include.
Review URL: https://codereview.chromium.org/1313203003
Reason for revert:
This causes a syntax error.
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_compile_dbg_ng/builds/87819/steps/compile%20%28with%20patch%29/logs/stdio
Original issue's description:
> Implement canComputeFastBounds() for image filters.
>
> Image filters have never implemented this check, which means that
> filters which affect transparent black falsely claim they can compute
> their bounds.
>
> Implemented an affectsTransparentBlack() virtual for image
> filters, and a similar helper function for color filters.
>
> This will affect the following GMs: imagefiltersscaled
> (lighting, perlin noise now filter to clip),
> colorfilterimagefilter (new test case), imagefiltersclipped
> (perlin noise now filters to clip).
>
> Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
> a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
> no impact from this change, but will watch the perf bots carefully.
>
> BUG=4212
>
> Committed: https://skia.googlesource.com/skia/+/915881fe743f9a789037695f543bc6ea189cd0cbTBR=reed@google.com,senorblanco@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=4212
Review URL: https://codereview.chromium.org/1300403003
Image filters have never implemented this check, which means that
filters which affect transparent black falsely claim they can compute
their bounds.
Implemented an affectsTransparentBlack() virtual for image
filters, and a similar helper function for color filters.
This will affect the following GMs: imagefiltersscaled
(lighting, perlin noise now filter to clip),
colorfilterimagefilter (new test case), imagefiltersclipped
(perlin noise now filters to clip).
Note: I de-inlined SkPaint::canComputeFastBounds() to avoid adding
a dependency from SkPaint.h to SkImageFilter.h.h. Skia benches show
no impact from this change, but will watch the perf bots carefully.
BUG=4212
Review URL: https://codereview.chromium.org/1296943002
