We've always been using the portable ColorRect32, so we don't need the
ColorRectProc plumbing.
Furthermore, ColorRect32 doesn't seem to be very important (we're only using
it in the opaque case, which our row-by-row procs already specialize for).
Remove that too.
If we find we want specialization for really narrow rects again, let's put it in
blitRect() directly. It's pretty unlikely we're going to get platform-specific
speedup for blits to non-contiguous memory.
My local SKP comparison is +- 3%... most neutral I've ever seen.
BUG=skia:
Review URL: https://codereview.chromium.org/959873002
There's a small window where two threads can both see the gen ID is zero,
both go get new distinct genIDs, but race to write them.
This now uses compare_exchange to read and leave the winner's ID in place
when there's a race.
SkAtomics isn't public.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/956013002
This extra atomic bool is hard to think about, and I'm worried about how
updates to fGenerationID and fUniqueGenerationID interlace. By storing
them in the same int, they can't ever race.
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
BUG=skia:
Review URL: https://codereview.chromium.org/955043002
Fix path bugs exposed by the path fuzzer.
Changes to existing gm and samplecode files defer their calls to construct
SkPath objects until the first draw instead of at test initialization.
Add an experimental call to SkPath to validate the internal SkPathRef.
Fix SkPath::addPoly to set the last moveto after adding a close verb.
Fix stroke to handle failures when computing the unit normal.
Add a unit test for the unit normal failure.
R=reed@google.com
Review URL: https://codereview.chromium.org/953383002
Like SkTRacy<T>, TSAN will not complain about these. Unlike SkTRacy<T>, TSAN
should not complain about these: SkAtomic<T> are threadsafe.
This should fix the races now suppressed in TSAN. As written, the memory
barriers we're using in SkPixelRef will be dumb but safe (really, dumbest
possible but safest possible). If we see a perf hit, we can follow up by
putting Ben and I in a room for a while, thinking about it really hard, and
using the minimum-strength safe memory barriers.
A refactor that steals a bit from the genID would also still be possible with
this approach.
BUG=chromium:437511
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
Review URL: https://codereview.chromium.org/955803002
Reason for revert:
This actually *does* change the public API - fID is now private, and it was being used on Android. See 5242b865d3/logs/build.log :
In file included from frameworks/base/libs/hwui/tests/../font/Font.cpp:26:0:
external/skia/src/core/SkGlyph.h: In member function 'android::uirenderer::CachedGlyphInfo* android::uirenderer::Font::cacheGlyph(const SkPaint*, glyph_t, bool)':
external/skia/src/core/SkGlyph.h:157:17: error: 'uint32_t SkGlyph::fID' is private
uint32_t fID;
^
frameworks/base/libs/hwui/tests/../font/Font.cpp:482:39: error: within this context
newGlyph->mGlyphIndex = skiaGlyph.fID;
We need to update Android in order to hide fID.
Original issue's description:
> BUG=skia:
>
> (mtklein from here on)
> No public API changes.
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/f8d24e2c0c7b44b7ccf20e40890514db4cde7b15TBR=mtklein@google.com,herb@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/951353002
SK_SUPPORT_LEGACY_GET_PIXELS_ENUM just set a \#define to convert
onGetPixelsEnum
to
onGetPixels
Now that Chrome has been updated to override onGetPixels, there is no
need for the define.
BUG=skia:3257
Review URL: https://codereview.chromium.org/933853004
Swap render target of the gpu device instead of creating a new gpu
device when making a copy-on-write upon surface modification.
This removes the SkCanvas::setRootDevice which contains problematic code
when trying to increase the use of SkImages internally in Skia.
BUG=skia:3388
Review URL: https://codereview.chromium.org/925343002
Reason for revert:
Broke callers in chrome
../../skia/ext/platform_canvas_unittest.cc:421:56: error: no member named 'isLocked' in 'SkPixelRef'
EXPECT_TRUE(platform_bitmap->GetBitmap().pixelRef()->isLocked());
Original issue's description:
> Make SkPixelRef::isLocked() debug-only, remove related dead code.
>
> DM's okay locally with no diffs, no failures.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/8e65712486c66108677a9b0a55ad3e7ca94db555TBR=reed@google.com,mtklein@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/940323003
All image compression currently uses (losseless) Deflate, not Jpeg.
All clients simply use SkDocument::CreatePDF(stream).
SampleApp and SkLua still use SkDocument::CreatePDF(path).
Review URL: https://codereview.chromium.org/935843007
Replace the old signature of onGetPixels (return bool) to return an
enum (Result). Remove onGetPixelsEnum.
Add a define for onGetPixelsEnum to onGetPixels. This is for staging
in Chromium, where some implementations override onGetPixelsEnum.
Add the define in skia_for_chromium_defines. Remove
SK_SUPPORT_LEGACY_IMAGE_GENERATOR_RETURN, which is no longer needed by
Chromium.
BUG=skia:3257
Review URL: https://codereview.chromium.org/939113002
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
