This allows users to create an Android font manager with their own set
of fonts, or augment the system set. This will allow for removal of
the current globals which are used for a similar, but more constained,
purpose.
BUG=skia:2817,skia:3314,chromium:407340
Review URL: https://codereview.chromium.org/887113002
SkWriter32::snapshotAsData() is no longer performance critical.
It's only used when we're serializing to disk.
BUG=skia:2289
Review URL: https://codereview.chromium.org/875403005
SkProxyCanvas is redundant with SkNWayCanvas, and means another class
we have to keep in sync with the SkCanvas interface.
Remove tests which use an SkProxyCanvas.
Requires a change to chromium.
BUG=skia:3279
BUG=skia:500
Review URL: https://codereview.chromium.org/886813002
SkTypeface already requires typeface streams to support SkStreamAsset
in practice, and in practice all users are already supplying them.
Review URL: https://codereview.chromium.org/869763002
Fold alpha to the inner savelayer in savelayer-savelayer-restore
patterns such as this:
SaveLayer (non-opaque)
Save
ClipRect
SaveLayer
Restore
Restore
Restore
Current blink generates these for example for SVG content such as this:
<path style="opacity:0.5 filter:url(#blur_filter)"/>
The outer save layer is due to the opacity and the inner one is due to
blur filter being implemented with picture image filter.
Reduces layers in desk_carsvg.skp testcase from 115 to 78.
BUG=skia:3119
Review URL: https://codereview.chromium.org/835973005
==7023== 5,056 (896 direct, 4,160 indirect) bytes in 8 blocks are definitely lost in loss record 947 of 2,656
==7023== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==7023== by 0x82CB99: SkNewImageFromBitmapTexture(SkBitmap const&, int, SkSurface::Budgeted) (SkImage_Gpu.cpp:64)
==7023== by 0x81A1CF: SkSurface_Gpu::onNewImageSnapshot(SkSurface::Budgeted) (SkSurface_Gpu.cpp:50)
==7023== by 0x694F9D: SkSurface::newImageSnapshot(SkSurface::Budgeted) (SkSurface_Base.h:92)
==7023== by 0x55EA7C: test_Surface(skiatest::Reporter*, GrContextFactory*) (SurfaceTest.cpp:485)
==7023== by 0x407CB2: run_test(skiatest::Test*) (DM.cpp:399)
==7023== by 0x408382: run_enclave_and_gpu_tests(SkTArray<Task, false>*) (DM.cpp:411)
==7023== by 0x68B71E: SkTaskGroup::wait() (SkTaskGroup.cpp:67)
==7023== by 0x40934E: dm_main() (DM.cpp:455)
==7023== by 0x409483: main (DM.cpp:477)
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu12-ShuttleA-GTX550Ti-x86_64-Release-Valgrind/builds/276/steps/dm/logs/stdioTBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/872183002
I have been hacking at this test trying to understand why the N5 is
still sometimes crashy (it seems, less but not zero now). No luck so far.
But, while I've been reading and hacking at it, I think I've made a
few small improvements, mostly to readability.
BUG=skia:
Review URL: https://codereview.chromium.org/870803002
This is a speculative fix for the crashing N5 bots. It looks like the bots are
always failing in or around FloatingPointTextureTest.
It looks like sometimes they're hitting a SIGBUS, which I suspect is stack
overflow. FloatingPointTextureTest allocates ~320K on the stack, which may
be too much. This CL moves those buffers to the heap. For consistency I did
the same with the half-float tests, though they're only using ~1/8th the stack.
It looks like sometimes the bots are failing to malloc. I don't understand that,
and this CL doesn't address that directly. But it's possible this is still a stack
overflow, just trashing RAM and causing arbitrary mayhem instead of a SIGBUS.
I have no idea why this is a problem only on the N5. I have been unable to
reproduce this locally, neither with a K N5 nor an L N5, but the bots are pretty
reliable.
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/871623002
SkStream is a stateful object, so it does not make sense for it to have
multiple owners. Make SkStream inherit directly from SkNoncopyable.
Update methods which previously called SkStream::ref() (e.g.
SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(),
which required the existing owners to call SkStream::unref()) to take
ownership of their SkStream parameters and delete when done (including
on failure).
Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some
cases this means heap allocating streams that were previously stack
allocated.
Respect ownership rules of SkTypeface::CreateFromStream() and
SkImageDecoder::buildTileIndex().
Update the comments for exceptional methods which do not affect the
ownership of their SkStream parameters (e.g.
SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be
explicit about ownership.
Remove test_stream_life, which tested that buildTileIndex() behaved
correctly when SkStream was a ref counted object. The test does not
make sense now that it is not.
In SkPDFStream, remove the SkMemoryStream member. Instead of using it,
create a new SkMemoryStream to pass to fDataStream (which is now an
SkAutoTDelete).
Make other pdf rasterizers behave like SkPDFDocumentToBitmap.
SkPDFDocumentToBitmap delete the SkStream, so do the same in the
following pdf rasterizers:
SkPopplerRasterizePDF
SkNativeRasterizePDF
SkNoRasterizePDF
Requires a change to Android, which currently treats SkStreams as ref
counted objects.
Review URL: https://codereview.chromium.org/849103004
Reason for revert:
Our Valgrind bot just spewed out a weird error. I don't know if it's related, but it looks at least like one of the stacks was in the right area, so I'm going to revert this precautionarily. Sorry if this is a false positive.
http://build.chromium.org/p/client.skia/builders/Test-Ubuntu12-ShuttleA-GTX550Ti-x86_64-Release-Valgrind/builds/266/steps/dm/logs/stdio
Original issue's description:
> Make GrScratchKey memory buffer correct size on copy
>
> Scratch key memory buffer of a copy of a key was too big. The (new) copy
> was N times uint32_t bytes instead of N bytes.
>
> Adds few tests to resource cache. These tests would not catch the too
> big buffer. This is just a precaution for too small buffers. The main
> idea of the test change is that the scratch key should contain some
> information, so that lookup with a scratch key can also return no
> match. Otherwise testing of scratch lookup result is not indicative of
> correct code (eg. no-information scratch key will always match).
>
> Committed: https://skia.googlesource.com/skia/+/711ef4831363fb8cbdf061dc2c36c65b13c0ccf2TBR=bsalomon@google.com,kkinnunen@nvidia.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/864833003
Scratch key memory buffer of a copy of a key was too big. The (new) copy
was N times uint32_t bytes instead of N bytes.
Adds few tests to resource cache. These tests would not catch the too
big buffer. This is just a precaution for too small buffers. The main
idea of the test change is that the scratch key should contain some
information, so that lookup with a scratch key can also return no
match. Otherwise testing of scratch lookup result is not indicative of
correct code (eg. no-information scratch key will always match).
Review URL: https://codereview.chromium.org/860333002
skiatest::Test class is now a simple struct. Some
functionalty, such as counting errors or timing is now
handled elsewhere.
skiatest:Reporter is now a simpler abstract class. The two
implementations handle test errors.
DM and pathops_unittest updated.
Review URL: https://codereview.chromium.org/830513004
