Move specialized SkPoint methods to SkPointPriv.
Use constexpr and inline initialization where possible.
R=reed@google.com,bsalomon@google.com
Bug: skia: 6898
Change-Id: I01ec5186f010f2dc80c068c70d9cc352f3221338
Reviewed-on: https://skia-review.googlesource.com/68700
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ravi Mistry <rmistry@google.com>
The latest, minor changes on includes already
generated, plus four new ones.
TBR=reed@google.com
Bug: skia:6898
Change-Id: If06ae9b9aaa3a0a9fae570aa7a6698ff340c43b8
Reviewed-on: https://skia-review.googlesource.com/62862
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
The TSAN bots fail regularly with races on fConvexity. Very annoying.
We used to have this very same problem with SkPath::fFirstDirection
until we made it atomic. This does the same to fConvexity.
This makes the field as lightly atomic as possible, with all operations
using a relaxed memory order. The value of fConvexity isn't guarding
any other non-atomic memory or implying any other writes have happened
so I don't think we need anything beyond relaxed here.
Change-Id: I0da1f892dc2b7072d692ce8b460fb1862aebef77
Reviewed-on: https://skia-review.googlesource.com/52180
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is a step towards not trusting deserialized isoval/isrrect for general paths without losing the performance advantages of knowing that a path is a rrect/oval.
Change-Id: I1a8c0608c0f29f4bf7a118dfa1d475e2ab5802ea
Reviewed-on: https://skia-review.googlesource.com/49761
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Fresh off the griddle versions of:
SkPaint.h, SkCanvas.h, SkPath.h, and SkPixmap.h.
TBR=reed@google.com
Bug: skia: 9868
Change-Id: If3f0c1cd7973c53482772c2478b12f1070c9fc4d
Reviewed-on: https://skia-review.googlesource.com/46587
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Cary Clark <caryclark@skia.org>
kPathRefGenIDBitCnt is used only by SkPath.cpp and SkPathRef.cpp.
Curiously, there's no existing private declarations shared by
SkPath and SkPathRef, so I added kPathRefGenIDBitCnt to
SkPathPriv.h as the go-between. If there's an existing convention
I overlooked, please let me know.
R=reed@google.com,djsollen@google.com
Bug: skia: 6898
Change-Id: I929d780c3b4a10e5cf78e7176a7516abf912508e
Reviewed-on: https://skia-review.googlesource.com/46560
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Cary Clark <caryclark@skia.org>
SkCanvas.h generated from docs/SkCanvas.bmh using bookmaker.
Also added corrections to SkPaint.h, and generated SkPath.h.
Once these are functionally correct (e.g., they don't break
anything) I plan to check them in -- feel free to continue
to review them before and after the check in event.
R=brianosman@google.comTBR=reed@google.com
Bug: skia:6898
Change-Id: I6d01e9eee422304e5ab871b3870a7ed710efd645
Reviewed-on: https://skia-review.googlesource.com/30460
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@skia.org>
Reviewed-by: Yuqian Li <liyuqian@google.com>
Work on SkPath.h documentation; fixed self-consistency
bugs identified by bookmaker. Fixed a couple of
minor typos in SkPath.h itself.
Also brought SkPaint and SkCanvas docs up to date.
TBR=reed@google.com
Docs-Preview: https://skia.org/?cl=39040
Bug: skia: 6898
Change-Id: Id89d4e2fa7fb6ee2e3cbec7ea762e06308b67d8b
Reviewed-on: https://skia-review.googlesource.com/39040
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@skia.org>
Reduce path validation interfaces,
deferring the harder work of rewriting
the callers until later.
R=reed@google.com,enne@chromium.org
Change-Id: Iea56f1cd1be93bb1d96b50836a9bd3cd4872ad23
Reviewed-on: https://skia-review.googlesource.com/37541
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Adrienne Walker <enne@chromium.org>
This was created by looking at warnings produced by clang's
-Wzero-as-null-pointer-constant. This updates most issues in
Skia code. However, there are places where GL and Vulkan want
pointer values which are explicitly 0, external headers which
use NULL directly, and possibly more uses in un-compiled
sources (for other platforms).
Change-Id: Id22fbac04d5c53497a53d734f0896b4f06fe8345
Reviewed-on: https://skia-review.googlesource.com/39521
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
As a part of serializing SkPaths, I want to be able to know (without
asserting) whether or not a path is valid so that I can discard
potentially malicious deserialized paths.
Currently, SkPath(Ref) both just have asserting validation functions
which can't be used externally. This patch adds accessors that don't
assert.
Bug: chromium:752755 skia:6955
Change-Id: I4d0ceb31ec660b87e3fda438392ad2b60a27a0da
Reviewed-on: https://skia-review.googlesource.com/31720
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
This reverts commit a4ce4b1f6b.
Fix SkPathRef deserialization malloc crash
If the path says it has more points/verbs/etc than the buffer could
be holding, then resetToSize could try to allocate something huge
and crash.
Bug: skia:
Change-Id: I23b8870e9f74386aca89fb8f9a60d3b452044094
Reviewed-on: https://skia-review.googlesource.com/26805
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Bug: skia:
Change-Id: I959287780ef94a258a6746132f3acb9f90e6c6cc
Reviewed-on: https://skia-review.googlesource.com/21863
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
I thought that SK_API on operator== was
redundant with SK_API on the enclosing class,
and was not needed. Turns out for mac_chromium_debug_ng
it is needed. Added comments for history.
Meanwhile, bookmaker found some missing and
mis-named parameters, so all is not lost.
R=reed@google.com
Change-Id: I88645666a9d06ec90c5ac133673460d6e6c75528
Reviewed-on: https://skia-review.googlesource.com/17277
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Mike Reed <reed@google.com>
These are the main problems we tend to hit with multithreaded drawing.
Change-Id: I63dc56f38a533eb839d36833e865af5fcc700d3b
Reviewed-on: https://skia-review.googlesource.com/9100
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
This also makes the required changed to src, tests, and tools. The few
public APIs modified by this change appear to be unused outside of Skia.
Removing these from the public API makes it easier to ensure users are
no longer using them.
This also updates GrGpu::wrapBackendXXX and the
::onWrapBackendXXX methods to clarify ownership.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2448593002
Review-Url: https://codereview.chromium.org/2448593002
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
Using Mike Klein's excellent coverage tool, increase the
unit testing of SkPath.cpp from 70% to 95%.
Along the way, determined that these functions were not
maintained or used:
SkPath::pathTo
SkPath::contains
as well as a large block of SkPath::cheapGetDirection().
Changed SkPath::validate() to permit infinities in
the path data points.
Fixed errors in preserving direction.
Fixed error setting direction when convexity is unknown.
Added missing conic to moveTo only detector.
BUG=
R=bsalomon@google.com, reed@google.com
Author: caryclark@google.com
Review URL: https://codereview.chromium.org/65493004
git-svn-id: http://skia.googlecode.com/svn/trunk@12291 2bbb7eff-a529-9590-31e7-b0007b416f81
- Moved the SkStrokeRec class in its own file
- Replaced SkStroke by SkStrokeRec in Ganesh
- Moved path stroking to the Ganesh level in some cases (everytime it isn't required to do it directly in SkGpuDevice). PathEffect and MaskFilter still require path stroking at the SkGpuDevice for now.
- Renamed static functions in SkPath with proper names
* No functionality shold have changed with this patch. This is a step towards enabling Ganesh Path Renderers to decide whether or not to stroke the path rather than always receiving the stroked path as an input argument.
BUG=chromium:135111
TEST=Try path rendering tests from the gm
Review URL: https://codereview.appspot.com/6946072
git-svn-id: http://skia.googlecode.com/svn/trunk@6861 2bbb7eff-a529-9590-31e7-b0007b416f81
Tease apart existing one rect path detector so
that a new variant can detect two nested rects as well.
Add tests to verify that both one and two rect
detectors both work and return the correct results.
Suppress other warnings in PathTest.
Review URL: https://codereview.appspot.com/6850059
git-svn-id: http://skia.googlecode.com/svn/trunk@6475 2bbb7eff-a529-9590-31e7-b0007b416f81
The fuzzer gets my vote as best test tool ever.
There are several issues outstanding: crashes in FixedPoint and a crash in the
path filling code that is most likely due to clipping problems (but maybe not).
BUG=425
Review URL: http://codereview.appspot.com/5503080
git-svn-id: http://skia.googlecode.com/svn/trunk@2936 2bbb7eff-a529-9590-31e7-b0007b416f81
Something is broken, and this will protect us while we sort it out.
Unreviewed.
git-svn-id: http://skia.googlecode.com/svn/trunk@2922 2bbb7eff-a529-9590-31e7-b0007b416f81
correct results for all stroke and fill modes even on the various types
of degenerate paths.
The goals of this patch include:
1. Have Skia store all of the verbs implied by path construction methods, even
if those define degenerate paths. The SVG implementation in WebKit, which is
backed by Skia, needs to know about all elements of the path, even degenerate
ones, for the correct drawing of markers and line caps. For example, in SVG you
should be able to draw a scatter plot by specifying a marker for vertices and
then giving a sequence of moveTo commands. Skia will not store the moveTos,
requiring a different storage mechanism.
2. Assuming 1, maintain the current Skia behavior. That is, make Skia robust to
degenerate paths.
3. Fix an existing bug in Skia where a degenerate moveTo-lineTo pair spits out
warnings from rasterization and produces incorrect results in inverse-fill
renderings.
4. Adds extensive testing for degenerate paths and path rendering in general.
To meet these goals, the patch I am proposing will result in minor additional
storage for degenerate paths (a few bytes per degenerate path, only if the user
defines such paths). There is also some additional overhead in the iteration
code, with the path now cleaned to remove degenerate segments as part of the
iteration process. I suspect this will also fix issues with computing normal
vectors to degenerate segments. Benchmarking suggests that this change may
result in slightly (< 1%) slower path drawing due to the checks for
degeneracy. This overhead could be removed (in fact, a significant speedup
could occur) if the results of iterating to clean up the path were cached.
This would cost memory, of course, and quite a bit of it.
BUG=398
TEST=tests/PathTest.cpp
gm/cubicpaths.cpp
gm/degeneratesegments.cpp
gm/movepaths.cpp
gm/linepaths.cpp
gm/quadpaths.cpp
Review URL: http://codereview.appspot.com/5482051
git-svn-id: http://skia.googlecode.com/svn/trunk@2901 2bbb7eff-a529-9590-31e7-b0007b416f81
