This bug chromium:662780 exists after our original fix (https://codereview.chromium.org/2477393002/) because this path (added in unit test) is calling blitAntiRect rather than blitAntiH when the path is drifted across the boundary. (The quadratic edge drifts across the boundary after an update and sets a dX=0 line segment which triggers blitAntiRect.)
Note that I didn't assert for the dLeft = dRite = 0 case because the left/right there won't drift after the SkTMin/SkTMax in line 964/966.
Theoretically we can revert the relaxation in https://codereview.chromium.org/2477393002/ (that's only a relaxation for analytic AA, not supersampled AA). However, consider that the initial landing of analytic AA is so painful, I decide to revert that relaxation only after our successful landing...
BUG=chromium:662780, chromium:662862
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2482193004
Review-Url: https://codereview.chromium.org/2482193004
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
Conics with very large w values can
be approximated with two straight lines.
This avoids iterating endlessly in an
attempt to create quadratics with unstable
numerics.
Check to see if the first chop generated
a pair of lines within the default
point comparison tolerance.
R=reed@google.com
BUG=643933, 643665
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2312923002
Review-Url: https://codereview.chromium.org/2312923002
$ git grep -l '<windows.h>' include src
include/private/SkLeanWindows.h
$ git grep -l SkLeanWindows.h | grep '\.h$'
include/ports/SkTypeface_win.h
include/utils/win/SkHRESULT.h
include/utils/win/SkTScopedComPtr.h
include/views/SkEvent.h
src/core/SkMathPriv.h
src/ports/SkTypeface_win_dw.h
src/utils/SkThreadUtils_win.h
src/utils/win/SkWGL.h
The same for `#include <intrin.h>` that was found in SkMath.h.
Those functions that needed it are moved to SkMathPriv.h.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2041943002
CQ_INCLUDE_TRYBOTS=tryserver.chromium.win:win_chromium_compile_dbg_ng,win_chromium_compile_rel_ng
Review-Url: https://codereview.chromium.org/2041943002
This function looks for "simple" rect paths. Simple here means begins and ends at a corner and is closed (either manually or with a close verb). Unlike SkPath::isRect this returns the starting point index (using the same start indexing scheme as SkPath::addRect).
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2017313002
Review-Url: https://codereview.chromium.org/2017313002
Pull out the logic to check to see if the point is on the edge
so all curve types can share.
Reorder cubic to be like conic and quad so that mixed types
consider the curves consistently.
Don't count on curve points twice if they are on the end
and compute a zero cross product.
Remove logic that checks, when there are no roots, if the
point is closer to the top or the bottom (it's always the top).
Initialize the iterator correctly when it is accessing
the list of on point curves.
Use 'multiply' instead of 'subtract' to see if the vectors
are pointing in opposite directions.
Add more test cases.
R=reed@google.com,fs@opera.com
BUG=skia:4265
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1532003004
Review URL: https://codereview.chromium.org/1532003004
Paths are cached as tessellated triangle meshes in vertex buffers on the GPU. Stroked paths are not (yet) cached.
Paths containing no curved segments (linear paths) are reused at all scales. Paths containing curved segments are reused within a scale tolerance threshold.
In order to invalidate the cache when an SkPath is changed or deleted,
this required implementing genID change notification in SkPath. This is
modelled almost exactly on SkPixelRef::GenIDChangeListener.
However, It does not currently implement the check for unique genIDs,
so notifiers will fire when the first instance of an SkPathRef
using a given genID is destroyed.
Another caveat is that you cannot successfully add a change notifier
to an empty path, since it uses the "canonical" empty path which is
never modified or destroyed. For this reason, we prevent adding
listeners to it.
BUG=skia:4121,skia:4122, 497403
DOCS_PREVIEW= https://skia.org/?cl=1114353004
Committed: https://skia.googlesource.com/skia/+/468dfa72eb6694145487be17876804dfca3b7adb
Review URL: https://codereview.chromium.org/1114353004
Paths are cached as tessellated triangle meshes in vertex buffers on the GPU. Stroked paths are not (yet) cached.
Paths containing no curved segments (linear paths) are reused at all scales. Paths containing curved segments are reused within a scale tolerance threshold.
In order to invalidate the cache when an SkPath is changed or deleted,
this required implementing genID change notification in SkPath. This is
modelled almost exactly on SkPixelRef::GenIDChangeListener.
However, It does not currently implement the check for unique genIDs,
so notifiers will fire when the first instance of an SkPathRef
using a given genID is destroyed.
Another caveat is that you cannot successfully add a change notifier
to an empty path, since it uses the "canonical" empty path which is
never modified or destroyed. For this reason, we prevent adding
listeners to it.
BUG=skia:4121,skia:4122, 497403
DOCS_PREVIEW= https://skia.org/?cl=1114353004
Review URL: https://codereview.chromium.org/1114353004
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
If a quad, cubic, or conic goes back on itself, assume it's not convex.
In a future CL, we could check to see if the curve is linear so that
linear curves are treated the same as lines.
BUG=skia:3469
Review URL: https://codereview.chromium.org/971773002
Without this patch the iterator can end up running off the end of the conic weights if there is a mixture of degenerate and non-degenerate ops
Note: we might want to suppress the generation of degenerate conics and lines in SkPath::addRRect
BUG=459897
Review URL: https://codereview.chromium.org/954453003
PathOps relies on isConvex() only returning true for trivially
convex paths. The old logic also returns true if the paths that
contain NaNs and Infinities. Return kUnknown_Convexity instead
in those cases and in cases where the convexity logic computes
intermediaries that overflow.
Review URL: https://codereview.chromium.org/784593002
This CL fixes the case where a bad initial vector (i.e., nearly zero) managed to short circuit all of the convexicator's logic. The initial bad vector would become the last vector and then never get displaced.
The history of this is:
https://codereview.chromium.org/298973004/
Switched the convexicator to not advance the last vector when the cross product wasn't significant
https://codereview.chromium.org/573763002/
Fixed a bug (crbug.com/412640) wherein a zero area path was being incorrectly categorized as convex b.c. opposite but equal vectors were not signaling concavity.
BUG=433683
Review URL: https://codereview.chromium.org/727283003
This will allow us to add nonnull-attribute to the UBSAN bot.
We are in fact hitting a case where one of the arguments is null and the other
not, which seems dicey. I think the scenario is comparing the empty pathref
with another path ref that's just been COWed, without any verbs or points yet.
BUG=skia:
Review URL: https://codereview.chromium.org/732643002
When calling cubicTo(a, b, c) and if the distance between fPrevPt and a
is too small, b is used instead of a to calculate the first tangent,
even if the distance between fPrevPt and b is too small.
In debug mode, this is causing an assertion to fail in
SkPathStroker::preJoinTo() and, in Release, the use of an
unitialized value.
The first patch set is adding a failing test.
The second one add the fix to SkPathStroker::cubicTo()
BUG=skia:2820
R=bsalomon@chromium.org, junov@chromium.org, reed@google.com, caryclark@google.com, bsalomon@google.com
Author: piotaixr@chromium.org
Review URL: https://codereview.chromium.org/460813002
This reduces the allocation overhead of a null picture (create, beginRecording(), endRecording) from about 18K to about 1.9K. (There's still lots more to prune.)
SkPictureFlat can exploit the fact that Writer32 is contiguous simplify its memory management. The Writer32 itself becomes the scratch buffer.
Remove lots and lots of arbitrary magic numbers that were size guesses and minimum allocation sizes. Keep your eyes open for the big obvious DUH why we save 16K per picture! (Spoiler alert. It's because that first save we issue in beginRecording() forces the old SkWriter32 to allocate 16K.)
Tests passing, DM passing.
bench --match writer: ~20% faster
null bench_record: ~30% faster
bench_record on buildbot .skps: ~3-6% slower, ranging 25% faster to 20% slower
bench_pictures on buildbot .skps: ~1-2% faster, ranging 13% faster to 28% slower
BUG=skia:1850
R=reed@google.com
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/137433003
git-svn-id: http://skia.googlecode.com/svn/trunk@13073 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
This temporarily disables SK_ENABLE_INST_COUNT
( skbug.com/1219 )
This fixes a linktime error on VS2012 in
PathTest.cpp; -SK_ScalarInfinity should be
SK_ScalarNegativeInfinity instead.
This adds pathops and pathops unit tests to the
main unit tests.
Should this change destabilize anything, it should
be sufficient to comment out the pathops gypi
includes. at test.gyp:18,21.
Review URL: https://codereview.chromium.org/14137010
git-svn-id: http://skia.googlecode.com/svn/trunk@8644 2bbb7eff-a529-9590-31e7-b0007b416f81
subDivide limit. This caused problems with degenate paths (too much recursion).
The fix was two parts:
1. decrement the subDivide limit as we recurse
2. up the limit for cubics to 7, to match our current quality
added unittest that replicated the too-much-recursion bug.
Review URL: https://codereview.chromium.org/14086002
git-svn-id: http://skia.googlecode.com/svn/trunk@8599 2bbb7eff-a529-9590-31e7-b0007b416f81
unused headers and fixes a couple of bugs exposed by changing the random
number generator:
First, the function SkMatrix::getMaxStretch() had an error where it was testing
the square of a number against near-zero. This led to it occasionally taking a
cheaper but imprecise path for computing the eigenvalues of the matrix. It's
been replaced with a check against the square of SK_ScalarNearlyZero.
The second case was a failure in ClipStackTest, where it hit the rare case of
a practically empty clip stack (it has a single Union) and we set a tight
bounds. The bounds rect doesn't get set by GrReducedClip::ReduceClipStack() in
this case, so when it clips the reduced stack it's clipping against garbage,
and the resulting regions don't match. The solution is to initialize the
tightBounds rect.
git-svn-id: http://skia.googlecode.com/svn/trunk@7952 2bbb7eff-a529-9590-31e7-b0007b416f81
I removed unused parameters in the tests wherever it was trivial to do so. I'm trying to get the easy ones out of the way before we get into more involved discussions around this.
Review URL: https://codereview.appspot.com/7394055
git-svn-id: http://skia.googlecode.com/svn/trunk@7891 2bbb7eff-a529-9590-31e7-b0007b416f81
This fixes crbug 170666. Before the fix, were were finishing the "clip" step
with a curve that was still partly negative, and so as assert would fire.
added unittest to confirm that the assert doesn't fire.
git-svn-id: http://skia.googlecode.com/svn/trunk@7278 2bbb7eff-a529-9590-31e7-b0007b416f81
of the cliprect, we (correctly) clamp the Y coordinate of the control-point
right next to the on-curve point that was chopped (this ensures we don't go
slightly outside of the clip-rect due to imperfect T value calculation). However,
the code was also clamping the other control-point as well, resulting in warping
the cubic, which could sometimes force it outside of the clip.
The fix is to just remove the line of code that clampped the 2nd control-point.
unittest added to reproduce a test cubic that triggered an assert, due to the
cubic being outside of the cliprect. The test (w/o the fix) will assert in
a SK_DEBUG build.
Review URL: https://codereview.appspot.com/7100056
git-svn-id: http://skia.googlecode.com/svn/trunk@7184 2bbb7eff-a529-9590-31e7-b0007b416f81
Allow a rect to start in the middle of a span, and
wrap all the way around.
Initialize variable to suppress warning.
Add tests to detect rects constructed from a stroked
path.
Review URL: https://codereview.appspot.com/6847082
git-svn-id: http://skia.googlecode.com/svn/trunk@6522 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
is monotonically going down, but the finite math we use cannot ensure that...
so we explicitly pin the y-value after it is calculated.
add unittest that exercises the bug/assert that was found on an SVG site
git-svn-id: http://skia.googlecode.com/svn/trunk@5544 2bbb7eff-a529-9590-31e7-b0007b416f81
canvas 2D interface. If there is a polyline, followed by a moveTo and a
closePath, both the moveTo and the closePath should be ignored for the purposes
of drawing, and the polyline should not be closed (unless force closed is true
(for filling, for instance).
Tested for path with both valid and degenerate content, when asked to
consume degenerates and not, force closed and not.
This patch also includes a uni test refactoring to reduce the amount of code
to test path iteration and zero length paths.
BUG=6297049
TEST=tests/PathTest.cpp, testIter method.
Review URL: https://codereview.appspot.com/6300086
git-svn-id: http://skia.googlecode.com/svn/trunk@4247 2bbb7eff-a529-9590-31e7-b0007b416f81
Fix these class of warnings:
- unused functions
- unused locals
- sign mismatch
- missing function prototypes
- missing newline at end of file
- 64 to 32 bit truncation
The changes prefer to link in dead code in the debug build
with 'if (false)' than to comment it out, but trivial cases
are commented out or sometimes deleted if it appears to be
a copy/paste error.
Review URL: https://codereview.appspot.com/6301045
git-svn-id: http://skia.googlecode.com/svn/trunk@4175 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
empty rects (since path.bounds must be the bounds of its control-pts, including
empty subcontours)
git-svn-id: http://skia.googlecode.com/svn/trunk@2679 2bbb7eff-a529-9590-31e7-b0007b416f81
I have manually examined all of these diffs and restored a few files that
seem to require manual adjustment.
The following files still need to be modified manually, in a separate CL:
android_sample/SampleApp/AndroidManifest.xml
android_sample/SampleApp/res/layout/layout.xml
android_sample/SampleApp/res/menu/sample.xml
android_sample/SampleApp/res/values/strings.xml
android_sample/SampleApp/src/com/skia/sampleapp/SampleApp.java
android_sample/SampleApp/src/com/skia/sampleapp/SampleView.java
experimental/CiCarbonSampleMain.c
experimental/CocoaDebugger/main.m
experimental/FileReaderApp/main.m
experimental/SimpleCocoaApp/main.m
experimental/iOSSampleApp/Shared/SkAlertPrompt.h
experimental/iOSSampleApp/Shared/SkAlertPrompt.m
experimental/iOSSampleApp/SkiOSSampleApp-Base.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Debug.xcconfig
experimental/iOSSampleApp/SkiOSSampleApp-Release.xcconfig
gpu/src/android/GrGLDefaultInterface_android.cpp
gyp/common.gypi
gyp_skia
include/ports/SkHarfBuzzFont.h
include/views/SkOSWindow_wxwidgets.h
make.bat
make.py
src/opts/memset.arm.S
src/opts/memset16_neon.S
src/opts/memset32_neon.S
src/opts/opts_check_arm.cpp
src/ports/SkDebug_brew.cpp
src/ports/SkMemory_brew.cpp
src/ports/SkOSFile_brew.cpp
src/ports/SkXMLParser_empty.cpp
src/utils/ios/SkImageDecoder_iOS.mm
src/utils/ios/SkOSFile_iOS.mm
src/utils/ios/SkStream_NSData.mm
tests/FillPathTest.cpp
Review URL: http://codereview.appspot.com/4816058
git-svn-id: http://skia.googlecode.com/svn/trunk@1982 2bbb7eff-a529-9590-31e7-b0007b416f81
