Make SkImage::getTexture() const. At the moment the function
does not mutate the state.
One use-case is that this makes it possible in the future to add draw
function to SkBaseDevice functions. The device draw functions take
const ref objects, but SkGpuDevice likely would benefit of using the
getTexture().
BUG=skia:3388
R=reed@google.com
Review URL: https://codereview.chromium.org/925853002
The new enum describes the nature of the failure. This is in
preparation for writing a replacement for SkImageDecoder, which will
use this interface.
Update the comments for getPixels() to specify what it means to pass
an SkImageInfo with a different size.
Make SkImageGenerator Noncopyable.
Leave onGetYUV8Planes alone, since we have separate discussions
regarding modifying that API.
Make callers of SkImageDecoder consistently handle kPartialSuccess.
Previously, some callers considered it a failure, and others considered
it a success.
BUG=skia:3257
Review URL: https://codereview.chromium.org/919693002
SkTHashTable is very similar to SkTDynamicHash, except it's generalized to support non-pointer value types.
It doesn't support remove(), just to keep things simple (it's not hard to add).
Instead of an iterator, it has foreach(), again, to keep things simple.
SkTHashMap<K,V> and SkTHashSet<T> build a friendlier experience on top of SkTHashTable.
BUG=skia:
Review URL: https://codereview.chromium.org/925613002
This allows for the removal of SkPath::mSourcePath on Android
as they now have a better indicator of whether or not the path
can be used again via the Java API.
Review URL: https://codereview.chromium.org/913413004
The language was being set to garbage, now set to part of the file name.
Add a test to ensure we continue to parse fallback directories correctly.
BUG=chromium:422180
Review URL: https://codereview.chromium.org/912053003
No algorithmic changes. The new APIs let us avoid a few ugly trips through void*,
and I've made the consume/acquire/release decision explicitly conditioned on TSAN.
This should fix the attached bug, which is TSAN seeing us implementing the
sk_consume_load() with a relaxed load, where we used to pass __ATOMIC_CONSUME
to TSAN. This restores us to the status quo of a couple weeks ago, where we
use relaxed loads (to avoid an extra dmb on ARM) for all setups except TSAN,
who gets the logically correct memory order, consume.
No public API changes.
TBR=reed@google.com
BUG=chromium:455606
Review URL: https://codereview.chromium.org/908943002
Implement SVG clips based on clip stack flattening -
which is now exposed in SkClipStack::asPath() and shared
with SkCanvas's simplify-clip code.
R=reed@google.com,mtklein@google.com
Review URL: https://codereview.chromium.org/876923003
This adds sk_memory_barrier(), implemented using sk_atomic_fetch_add() on an uninitialized variable. If that becomes a problem we can drop this to the porting layer, using std::atomic_thread_fence() / __atomic_thread_fence() / __sync_synchronize().
The big win is that ref() doesn't generate a memory barrier any more on ARM.
This is an instance of SkSafeRef() in SkPaint(const SkPaint&) after this CL:
4d0: 684a ldr r2, [r1, #4]
4d2: 6018 str r0, [r3, #0]
4d4: b13a cbz r2, 4e6 <_ZN7SkPaintC1ERKS_+0x2e>
4d6: 1d10 adds r0, r2, #4
4d8: e850 4f00 ldrex r4, [r0]
4dc: 3401 adds r4, #1
4de: e840 4500 strex r5, r4, [r0]
4e2: 2d00 cmp r5, #0
4e4: d1f8 bne.n 4d8 <_ZN7SkPaintC1ERKS_+0x20>
Here's the before, pretty much the same with two memory barriers surrounding the ref():
4d8: 684a ldr r2, [r1, #4]
4da: 6018 str r0, [r3, #0]
4dc: b15a cbz r2, 4f6 <_ZN7SkPaintC1ERKS_+0x3e>
4de: 1d10 adds r0, r2, #4
4e0: f3bf 8f5f dmb sy
4e4: e850 4f00 ldrex r4, [r0]
4e8: 3401 adds r4, #1
4ea: e840 4500 strex r5, r4, [r0]
4ee: 2d00 cmp r5, #0
4f0: d1f8 bne.n 4e4 <_ZN7SkPaintC1ERKS_+0x2c>
4f2: f3bf 8f5f dmb sy
The miscellaneous files in here are just fixups to explicitly include SkMutex.h,
instead of leeching it off SkRefCnt.h.
No public API changes.
TBR=reed@google.com
Build trybots seem hosed.
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/896803002
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
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
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
