Extend the ends of hairline and haircurve segments when the paint is set to square or round, and the line or curve is at the start or end of a contour.
R=reed@google.com
BUG=skia:4599
Review URL: https://codereview.chromium.org/1491843006
Add helper to track when a round rect was added to a path,
and then return the SkRRect specification that describes it.
Move the implementation for SkPath::RawIter to SkPathRef so it can be used there as well.
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1461763004
Extend the SkPath API to allow specifying the contour starting point.
This will allow removing the explicit cubic code from Blink/Path.
BUG=chromium:315277
R=reed@google.com,caryclark@google.com
Review URL: https://codereview.chromium.org/1452203002
We landed this originally with lazily-correct sequentially-consistent memory
order. It turns out that's regressed performance, we think particularly when
recording paths. We also think there's no need for anything but relaxed memory
order here.
We should see this chart go down if all goes well: https://perf.skia.org/#4329
There are also Chrome performance charts to watch in the linked bug.
BUG=chromium:537700
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-TSAN-Trybot,Test-Ubuntu-GCC-Golo-GPU-GT610-x86_64-Release-TSAN
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1393833003
This is a contract change for SkPath::getBounds(), which formally was defined to return 0,0,0,0 for a 1-point path, regardless of the coordinates of that point. This seems wacky/inconsistent, and was causing other bugs (incorrect bounds) when this was unioned with other rects.
Does anyone remember why we defined it this way?
BUG=513799
Review URL: https://codereview.chromium.org/1261773002
and are treated as convex when they are not.
Allow the SkPath::Iter to leave degenerate path
segments unmolested by passing an additional exact
bool to next().
Treat any non-zero length as significant in addPt().
R=reed@google.com,robertphillips@google.com
BUG=493450
Review URL: https://codereview.chromium.org/1228383002
- input param to addFoo (e.g. addRect), where only CW or CCW are valid)
- output param from computing functions, that sometimes return kUnknown
This CL's intent is to split these into distinct enums/features:
- Direction (public) loses kUnknown, and is only used for input
- FirstDirection (private) is used for computing the first direction we see when analyzing a contour
BUG=skia:
Review URL: https://codereview.chromium.org/1176953002
All but 17 extended tests work.
A helper function is privately added to SkPath.h to permit a test to modify a given point in a path.
BUG=skia:3588
Review URL: https://codereview.chromium.org/1107353004
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
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
This code requires fewer macros to use it (just one), has less code in macro
definitions, and has simpler synchronization code (just atomic ints, no SkOnce,
no SkMutex, etc.)
A minor downside, we lose indentation and reverse-ordering in the final report:
Leaked SkRefCntBase: 7
Leaked SkFontMgr: 1
Leaked SkWeakRefCnt: 1
Leaked SkTypeface: 1
Leaked SkFlattenable: 3
Leaked SkXfermode: 3
Leaked SkPathRef: 1
Leaked SkPixelRef: 1
Leaked SkMallocPixelRef: 1
becomes
Leaked SkXfermode: 3
Leaked SkMallocPixelRef: 1
Leaked SkPixelRef: 1
Leaked SkPathRef: 1
Leaked SkFlattenable: 3
Leaked SkTypeface: 1
Leaked SkWeakRefCnt: 1
Leaked SkFontMgr: 1
Leaked SkRefCntBase: 7
This is motivated by wanting to land https://codereview.chromium.org/806473006/,
which makes sure all static use of SkOnce are in global scope. The current
implementation of SkInstCnt uses them in function scope, which isn't safe.
BUG=skia:
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/841263004
Any path that is generated frame-to-frame should not be rendered by using the
DistanceFieldPathRenderer, because generating the initial distance field,
uploading it and rendering it takes longer than the SoftwarePathRenderer.
BUG=skia:2935
Review URL: https://codereview.chromium.org/677463002
There's little benefit to deduping matrices and regions: they're infrequently
used, and doubly infrequently reused. Their use-weighted byte cost is tiny.
There is some downside to deduping matrices and regions. Even when they're not
used, we prepare dictionaries for deduping them for every picture. Each of
these dictionaries costs 160 bytes, so two unused dictionaries make a big chunk
of the ~1100 bytes it takes to allocate an SkPictureRecord. (~330 come from
parent class SkCanvas, 768 from SkPictureRecord itself, here reduced to 448).
One side benefit of not deduping these guys is that the change weighs -140 lines of code.
It may go without saying, but this breaks the picture format.
Testing: out/Debug/tests && out/Debug/dm (which runs all picture modes by default)
BUG=skia:1850
R=reed@google.com, bensong@google.com, robertphillips@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/143883006
git-svn-id: http://skia.googlecode.com/svn/trunk@13149 2bbb7eff-a529-9590-31e7-b0007b416f81
