This doesn't add them to the second-stringer Sk4i. It's unclear we should be
doing that often, and we don't have efficient ways to do it except via floats.
BUG=skia:
Review URL: https://codereview.chromium.org/964603002
This path renderer converts paths to linear contours, resolves intersections via Bentley-Ottman, implements a trapezoidal decomposition a la Fournier and Montuno to produce triangles, and renders those with a single draw call. It does not currently do antialiasing, so it must be used in conjunction with multisampling.
A fair amount of the code is to handle floating point edge cases in intersections. Rather than perform exact computations (which would require arbitrary precision arithmetic), we reconnect the mesh to reflect the intersection points. For example, intersections can occur above the current vertex, and force edges to be merged into the current vertex, requiring a restart of the intersections. Splitting edges for intersections can also force them to merge with formerly-distinct edges in the same polygon, or to violate the ordering of the active edge list, or the active edge state of split edges.
BUG=skia:
Review URL: https://codereview.chromium.org/855513004
Reason for revert:
TSAN troubles.
Original issue's description:
> Use an image generator to back SkPictureShader tiles.
>
> To avoid lifetime issues for tiles backed by discardable memory, use an
> image generator to re-generate them on the fly.
>
> With this CL, we are now caching bitmap shaders wrapping discardable
> pixel ref bitmaps backed by picture image generators.
>
> (the CL also includes some minor/unrelated SkPictureShader cleanup)
>
> BUG=skia:3220
> R=reed@google.com,halcanary@google.com
>
> Committed: https://skia.googlesource.com/skia/+/4739955e98ba86900a5bbac0e3661601427a54d4TBR=reed@google.com,halcanary@google.com,mtklein@google.com,reed@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:3220
Review URL: https://codereview.chromium.org/956143002
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
Removes the disabled SSE2 optimization of ColorRect32 and deletes
the two files containing the code.
Measured on both Core Haswell and Atom Silvermont, and only got
some miniscule improvement compared to the default implementation.
Also tried to write a new, ultimate, version of this optimization,
but only got ~5% improvement on ColorRect32-heavy tests.
Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>
Review URL: https://codereview.chromium.org/957433002
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
To avoid lifetime issues for tiles backed by discardable memory, use an
image generator to re-generate them on the fly.
With this CL, we are now caching bitmap shaders wrapping discardable
pixel ref bitmaps backed by picture image generators.
(the CL also includes some minor/unrelated SkPictureShader cleanup)
BUG=skia:3220
R=reed@google.com,halcanary@google.com
Review URL: https://codereview.chromium.org/866773002
This doesn't do anything about the issue of having too many indices, but it does move the fuzzer on to another assert.
BUG=skia:
Review URL: https://codereview.chromium.org/952993004
This should look suspiciously similar to tools/dm_flags.py. In fact, I
tweaked tools/dm_flags.py a bit to make it even more suspiciously similar.
I'll leave actually deduping this to future me.
I noticed we have an opportunity to make our Valgrind run of nanobench faster,
by not only making it not auto-calibrate (--loops 1) but also take only one
measurement (--samples 1). Should be 5-10x faster than the default.
BUG=skia:
Review URL: https://codereview.chromium.org/957503002