This merges and refactors SkAtomics.h and SkBarriers.h into SkAtomics.h and
some ports/ implementations. The major new feature is that we can express
memory orders explicitly rather than only through comments.
The porting layer is reduced to four template functions:
- sk_atomic_load
- sk_atomic_store
- sk_atomic_fetch_add
- sk_atomic_compare_exchange
From those four we can reconstruct all our previous sk_atomic_foo.
There are three ports:
- SkAtomics_std: uses C++11 <atomic>, used with MSVC
- SkAtomics_atomic: uses newer GCC/Clang intrinsics, used on not-MSVC where possible
- SkAtomics_sync: uses older GCC/Clang intrinsics, used where SkAtomics_atomic not supported
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/896553002
Decades ago Intel decided that the bsr (Bit Scan Reverse) instruction
should have undefined results if its argument is zero. This probably
makes the instruction harder to implement and it definitely makes it
more difficult to use.
In SkCLZ_portable it requires a check for a zero argument, but despite
that check /analyze still warns that _BitScanReverse might fail
(because it doesn't know what can cause failures). Because this warning
occurs in a frequently included header file it ends up being very noisy,
accounting for ~30% of all warnings (before deduplication).
Suppressing this useless warning will make the raw results easier to
look through.
Review URL: https://codereview.chromium.org/872673007
Eventually, this will be moved to be a peer of SampleApp so it is compiled by the bots to avoid future bit rot.
Also ignore XCode auto-generated flag in CommandLineFlags, and remove the unused multiple-example part.
Review URL: https://codereview.chromium.org/890873003
This method is not called anywhere on Android or Chrome, and it
has a FIXME that it may not be correct.
A client can still getLocalMatrix().isIdentity() if they need this
information. (It has the same FIXME, and perhaps we should revisit
it. In the meantime, this convenience method is not needed.)
Review URL: https://codereview.chromium.org/882443007
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
This is necessary for multisampling, so that each multisampled render
target resolves before Chrome's compositor attempts to draw the
texture.
BUG=skia:
Review URL: https://codereview.chromium.org/878653004
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
This fixes two problems:
1) #include SK_SOME_DEFINE doesn't work well for all our clients.
2) Things in include/ are #including things in src/, which we don't like.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/862983002
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
