Reason for revert:
hidden symbol 'AnnotateBenignRaceSized' in obj/base/third_party/dynamic_annotations/libdynamic_annotations.a(obj/base/third_party/dynamic_annotations/dynamic_annotations.dynamic_annotations.o) is referenced by DSO lib/libblink_platform.so
Original issue's description:
> Add SkRacy
>
> SkRacy<T> is a zero-overhead wrapper for a T, except it also
> silences race warnings when TSAN is running.
>
> Here we apply in several classes. In SkMatrix and SkPathRef,
> we use it to opportunistically cache some idempotent work.
>
> In SkPixelRef, we wrap the genIDs. We think the worst that
> can happen here is we'll increment the global next-genID a
> few times instead of once when we go to get another ID.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/d5e3e6ae1b3434ad1158f441902ff65f1eeaa3a7R=reed@google.com, mtklein@chromium.orgTBR=mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/377693005
SkRacy<T> is a zero-overhead wrapper for a T, except it also
silences race warnings when TSAN is running.
Here we apply in several classes. In SkMatrix and SkPathRef,
we use it to opportunistically cache some idempotent work.
In SkPixelRef, we wrap the genIDs. We think the worst that
can happen here is we'll increment the global next-genID a
few times instead of once when we go to get another ID.
BUG=skia:
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371363004
Now that all creation of SkImageFilters goes through
factory Create() methods, there's no real reason for the
convenience constructors. Some SkImageFilter subclasses
which actually have zero DAG-able inputs were passing NULL
to the superclass constructor. This actually means 1 input,
with a NULL value, not zero inputs. This becomes more
relevant for the upcoming cache infrastructure, where this
indicates that the filter will use its src input, where in
fact some of these filters do not (they are image generators
only).
Limiting SkImageFilter to a single constructor resolves this
ambiguity.
Along the way, I removed all of the default parameters to
the constructors, since the Create methods always call them
with the full argument list.
BUG=skia:
R=reed@google.com
Author: senorblanco@chromium.org
Review URL: https://codereview.chromium.org/376953003
This CL begins setting up the SkPicturePlayback split by simplifying the class and componentizing it a bit. It:
fuses SkPictureData::OperationList into SkPicture::OperationList
adds a handleOp method to SkPicturePlayback that can be reused by derived classes
removes a couple debugging tools (ENABLE_TIME_DRAW & SPEW_CLIP_SKIPPING)
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/378703002
Symptom: draw Index8 to RGB565 will using SkColorTable::lock16BitCache and return a null array.
Root Cause:lock16BitCache return null pointer because default type is kPremul_SkAlphaType
Solution: WBMP color table should be kOpaque_SkAlphaType
Reproduce steps: draw a WBMP with a matrix that apply rotate and transform
This patch was proposed by arthur_hung at htc.com to the AOSP project.
R=reed@google.com, scroggo@google.com
Review URL: https://codereview.chromium.org/377443007
Currently X with most Window managers calls 'exit' when the close button
is used. This can cause issues as the Window is not properly destroyed.
With this change we can handle this window message and properly exit.
R=reed@google.com
Author: bungeman@google.com
Review URL: https://codereview.chromium.org/377733002
This is a first piece of the GPU YUV decoder, which is the actual effect that performs the conversion. For now, it simply applies the conversion matrix, since it is all I need. I may add modes if different matrices need to be applied or if I add color profile support here.
I'll try to keep these cls short and easy to review, but there should be a few of them coming once this one is in.
BUG=skia:
R=senorblanco@chromium.org, senorblanco@google.com, reed@google.com, bsalomon@google.com
Author: sugoi@chromium.org
Review URL: https://codereview.chromium.org/378503006
This splits the playback functionality out of SkPictureData. The old SkPictureData::draw method is pulled out along
with its supporting functions as verbatim as possible. Some follow on CLs will be required to:
re-enable profiling in the debugger (and remove the vestiges of SkTimedPicture)
re-enable display of command offsets in the picture (this should probably wait until we've switched to SkRecord though)
Clean up CachedOperationList (maybe fuse with SkPicture::OperationList)
Split SkPicturePlayback into a base class and two derived classes
Implement parallel version of GatherGPUInfo for SkRecord
Landing this is blocked on removing Android's use of the abortPlayback entry point.
R=mtklein@google.com, reed@google.com
Author: robertphillips@google.com
Review URL: https://codereview.chromium.org/377623002
We're racing to invalidate the genID of our pixel ref when multiple
threads write into it, and also to call its genID-changed listeners.
We install no listeners on this particular pixel ref, nor do we ever
care about its genID at all. So these are benign races, races on
data we never make a decision from.
BUG=skia:2725
R=jcgregorio@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/370353004
Now that we're drawing tiles threaded like implside painting, remove the checks
that those lock counts are balanced. They're just not right for anyone anymore.
SkBitmaps themselves are not threadsafe (even const ones), so shallow copy them
on playback of an SkRecord. (The underlying SkPixelRefs are threadsafe.)
Simplify quilt drawing by using SkBitmap::extractSubset. No need for locking.
Bump up to 256x256 tiles. 16x16 tiles just murders performance (way too much
contention). This has the nice side effect of letting us enable a bunch more
GMs for quilt mode; they drew wrong with small tiles but exactly right with large.
BUG=171776
R=reed@google.com, mtklein@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/371023005
