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
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
- use C++11 features ({} init, move constructors) to eliminate the need
for explicit constructors
- collapse RECORD0...RECORD8 into just one RECORD macro
- explicitly tag record types instead of using member detectors.
Removing member detectors makes this code significantly less fragile.
This exposes a few places where we didn't really think through what to do
with SkDrawable. I've marked them TODO for now.
BUG=skia:
Review URL: https://codereview.chromium.org/1360943003
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
The test "nullptr == fBlockMemory->fHead->fNext" tests that
all of the data is in one block, but it is also necessary to
test "fBlockMemory->fHead" to ensure that there is a first
block with data in it.
Review URL: https://codereview.chromium.org/1374493002
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
These tests were isolated from their respective minimized test cases.
The tests work fine and pass path ops internal validation;
hopefully some more intensive x-san or valgrind test will help
isolate the bug.
Sheriff, please revert if it fails and I don't get to it first.
TBR=reed@google.com,halcanary@google.com
BUG=535127,535151
Review URL: https://codereview.chromium.org/1359263003
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
libjpeg-turbo turns on dithering by default. When we
decode to RGBA, it uses Floyd-Steinberg dithering -
consistent with the libjpeg6b gold standard,
When we decode to 565, it uses ordered dithering. Ordered
dithering for 565 is not part of the 6b standard (libjpeg6b
doesn't even support 565) and is causing us a number of
issues:
(1) Ordered dithering + nearest neighbor sampling is
causing checkerboard visual artifacts in some outputs.
(2) The ordered dither function in libjpeg-turbo actually
behaves differently depending on the alignment of the
memory that it decodes into. This means that two image
decodes that should be identical may look different just
because they decode into different memory blocks. This
was causing some diffs on Gold with the scanline_subset
test that were causing me some confusion.
(3) Maybe not the best evidence, but visually I can't tell
a difference with and without dithering (except when
nearest neighbor scaling causes the checkerboard artifact).
(4) Turning off dithering should be a more significant
performance improvement than you might expect.
libjpeg-turbo has SIMD color conversions to 565, but when
dithering is on, it defaults to scalar code.
This CL should make every jpeg decode to 565 on Gold look
slightly different. Yay!
BUG=skia:
Review URL: https://codereview.chromium.org/1349563007
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
Blink is migrating away from SkBitmaps, so we need an SkImage-based
SkImageFilter source. This is pretty much a 1-1 equivalent of
SkBitmapSource.
To avoid duplication, relocate the SkImage deserialization logic
from SkPictureData to SkReadBuffer.
R=reed@google.com,robertphillips@google.com,senorblanco@chromium.org
Review URL: https://codereview.chromium.org/1343703005
The new flow of calls for attaching a Stencil looks like:
Client
rt->attachStencilAttachment()
gpu->getStencilAttachment()
glgpu->createStencilAttachment()
glrt->completeStencilAttachment() //actually attaches
BUG=skia:
Review URL: https://codereview.chromium.org/1333383002
Had to move GrComposeEffect class definition from SkComposeShader.cpp to SkComposeShader.h so that GLProgramsTest can call GrComposeEffect::Create()
BUG=skia:4182
Review URL: https://codereview.chromium.org/1314923002
Reason for revert:
DEPS should be fixed now
Original issue's description:
> Revert of more zero-length changes for svg compatibility (patchset #6 id:100001 of https://codereview.chromium.org/1330623003/ )
>
> Reason for revert:
> breaks DEPS
>
> Original issue's description:
> > more zero-length changes for svg compatibility
> >
> > 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
> >
> > Committed: https://skia.googlesource.com/skia/+/62fb1ba1786863e545c89839b5706ad5151cec15
>
> TBR=fs@opera.com,reed@google.com
> NOPRESUBMIT=true
> NOTREECHECKS=true
> NOTRY=true
> BUG=22974
>
> Committed: https://skia.googlesource.com/skia/+/5ca4fa3846067a47e88d35ace895df3ebe3ec2a5TBR=fs@opera.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=22974
Review URL: https://codereview.chromium.org/1314833004
Reason for revert:
breaks DEPS
Original issue's description:
> more zero-length changes for svg compatibility
>
> 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
>
> Committed: https://skia.googlesource.com/skia/+/62fb1ba1786863e545c89839b5706ad5151cec15TBR=fs@opera.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=22974
Review URL: https://codereview.chromium.org/1334543002
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
