This is in prep for compiling with -std=c++14 and -Wno-c++17-extensions
when building with clang. Chrome has encountered problems with
third_party headers that are included both in Skia and other Chrome
sources that produce different code based on whether preprocessor macros
indicate a C++14 or C++17 compilation.
In C++17 they are already inline implicitly. When compiling with C++14
we can get linker errors unless they're explicitly inlined or defined
outside the class. With -Wno-c++17-extensions we can explicitly inline
them in the C++14 build because the warning that would be generated
about using a C++17 language extension is suppressed.
We cannot do this in public headers because we support compiling with
C++14 without suppressing the C++17 language extension warnings.
Bug: chromium:1257145
Change-Id: Iaf5f4c62a398f98dd4ca9b7dfb86f2d5cab21d66
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/457498
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
If we manage to fix all the existing cases of variable shadowing, we
could enable -Wshadow.
Change-Id: I4c476668a83a0054fe8624d5ffa650db202ba810
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/438376
Auto-Submit: John Stiles <johnstiles@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
With variable width stroke, there is a curious case where both sides
need an inner or an outer join, instead of the fixed width case where
each side will have opposite join types. This improves the miter join
logic to treat the "left" and "right" sides separately.
There is still work to be done for joins, it's still too easy to create
weirdness.
Also improved debugging messages for degenerate cases instead of
silently swallowing the errors.
Change-Id: I4b6819e200138b39409b874a492b920d78f6a588
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/330155
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
I left in the ability to swap between using % arc length versus dividing
t evenly up across path segments so we can easily visually compare the
effect.
Change-Id: Id83792aa9e22fd5464e956092bac0baec389ffed
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/330103
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
The major difference in computing the join geometry is just that we must
use normal and radius information from the approximated offsets, instead
of the input geometry. All that effectively means is that we need to
stroke the next segment prior to being able to add a join with the
previous segment.
Change-Id: I44d9015cf534deeae27db3c3faab965aee3e930b
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329618
Reviewed-by: Tyler Denniston <tdenniston@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
- Currently supports single-segment paths (lines or quads). Doesn't
handle joins.
- Cubics are easy to add but not supported yet.
- No effort was made on performance optimization.
- Will likely be relocated eventually into an experimental SkPathEffect.
Change-Id: I35073d1d9dbc03a5423fda3bb20da005964c97d6
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/329256
Reviewed-by: Chris Dalton <csmartdalton@google.com>
Commit-Queue: Tyler Denniston <tdenniston@google.com>
