Bug: skia:
Change-Id: I11ff57dca2c48519bc3a23e36da01bf40d1b329c
Reviewed-on: https://skia-review.googlesource.com/c/174221
Commit-Queue: Mike Reed <reed@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
In theory, a convex shape is still convex if transformed by an affine
matrix. However, SkPath segments are specified using floats, and attributes
like collinearity can break under some transforms due to finite precision.
Computing convexity is non-trivial, so there is value in SkPath caching this
calculation. Convexity is useful, as both the CPU and GPU backends can draw
convex shapes faster than non-convex.
To balance these two (fragile float math and value of caching convexity),
this CL invalidates this cached state if the transform could change convexity.
In the general case, it is assumed that convexity could change. Special cases
where it is safe to keep the cached state after transform are:
- identity transform
- scale/translate transform if the path is known to be axis-aligned
All other combinations invalidate the cached state, forcing it to be
recomputed.
"axis-aligned" means the segments in the path are all axis-aligned, horizontal
or vertical (e.g. a rect or rrect)
Bug: 899689
Change-Id: I1381273eaff61d6b7134ae94b4f251c69991081a
Reviewed-on: https://skia-review.googlesource.com/c/173226
Commit-Queue: Ravi Mistry <rmistry@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
This reverts commit 26d8d77aae.
Reason for revert: speculative, in case this is blocking the chrome roll
Original change's description:
> don't trust convexity with affine transforms
>
> In theory, a convex shape transformed by an affine matrix should still
> be convex. However, due to numerical nastiness of floats, when we try
> to determine if something is convex, we can get different answers pre
> and post a transformation (think of two line segments nearly colinear).
>
> Convex paths take a faster scan converter, but it is only well behaved
> if the path is, in fact, convex. Thus we have to be conservative about
> which paths we mark as convex.
>
> This bug found a case where a "convex" path, after going through a transform,
> became (according to our measure) non-convex. The bug was that we *thought*
> that once convex always convex, but in reality it was not. The fix (hack) is
> to notice when we transform by an affine matrix (we're still assuming/hoping
> that scaling and translate keep things convex (1)...) and mark the convexity
> as "unknown", forcing us to re-compute it.
>
> This will slow down these paths, since it costs something to compute convexity.
> Hopefully non-scale-translate transforms are rare, so we won't notice the
> speed loss too much.
>
> (1) This is not proven. If we find scaling/translation to break our notion of
> convexity, we'll need to get more aggressive/clever to find a fix.
>
>
> Bug: 899689
> Change-Id: I5921eca247428bf89380bc2395fe373fa70deb1d
> Reviewed-on: https://skia-review.googlesource.com/c/173080
> Commit-Queue: Mike Reed <reed@google.com>
> Reviewed-by: Cary Clark <caryclark@google.com>
> Reviewed-by: Jim Van Verth <jvanverth@google.com>
TBR=mtklein@google.com,jvanverth@google.com,caryclark@google.com,reed@google.com,caryclark@skia.org
Change-Id: I5d846798f2c34c6576591a3c3125cfdc3c72dbdc
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 899689
Reviewed-on: https://skia-review.googlesource.com/c/173162
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
In theory, a convex shape transformed by an affine matrix should still
be convex. However, due to numerical nastiness of floats, when we try
to determine if something is convex, we can get different answers pre
and post a transformation (think of two line segments nearly colinear).
Convex paths take a faster scan converter, but it is only well behaved
if the path is, in fact, convex. Thus we have to be conservative about
which paths we mark as convex.
This bug found a case where a "convex" path, after going through a transform,
became (according to our measure) non-convex. The bug was that we *thought*
that once convex always convex, but in reality it was not. The fix (hack) is
to notice when we transform by an affine matrix (we're still assuming/hoping
that scaling and translate keep things convex (1)...) and mark the convexity
as "unknown", forcing us to re-compute it.
This will slow down these paths, since it costs something to compute convexity.
Hopefully non-scale-translate transforms are rare, so we won't notice the
speed loss too much.
(1) This is not proven. If we find scaling/translation to break our notion of
convexity, we'll need to get more aggressive/clever to find a fix.
Bug: 899689
Change-Id: I5921eca247428bf89380bc2395fe373fa70deb1d
Reviewed-on: https://skia-review.googlesource.com/c/173080
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Spoiler alert... it doesn't.
Bug: oss-fuzz:10488
Change-Id: Ifafd92f40aed55ff14a5198ea7d79a20751e40aa
Reviewed-on: https://skia-review.googlesource.com/156661
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Add header and .bmh docs for shrinkToFit().
Also remove SkPath::debugging_private_getFreeSpace() and refactor tests
to use (friended) helper classes.
Docs-Preview: https://skia.org/?cl=153668
Change-Id: I3f93f9561b25025ce04a81d5e2f0271295b3daad
Reviewed-on: https://skia-review.googlesource.com/153668
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
UBSAN points out that -1 isn't required to be representable
in a FirstDirection, but I think the union of all possible
fields is.
In this case, the union is 3, oring together CW (0), CCW (1)
and Unknown (2). Since it's not one of the meaningful values
of the enum, it works as a nice sentinel.
Change-Id: Ib428a8f0d7f5edbf492501306604ba57e9d19e38
Reviewed-on: https://skia-review.googlesource.com/147002
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
We're testing here that when isRect() returns false,
the isClosed and direction fields are unchanged.
Instead of using illegal values (which trip up UBSAN)
test all combinations of legal values.
It looks like we were trying to use an illegal -1 bool
to do the same trick as the enum, but I think it was
legal and just always true.
Change-Id: Ia4ab4c3d52f61bf67e888dea67549ab09750902a
Reviewed-on: https://skia-review.googlesource.com/147001
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Use std::swap instead. It does not appear that any external user
specializes SkTSwap, but some may still use it. This removes all use in
Skia so that SkTSwap can later be removed in a smaller CL. After that
the <utility> include can be removed from SkTypes.h.
Change-Id: If03d4ee07dbecda961aa9f0dc34d171ef5168753
Reviewed-on: https://skia-review.googlesource.com/135578
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
This reverts commit 2a2f675926.
Reason for revert: this appears to be what is holding up the Chrome roll.
Original change's description:
> SkTypes: extract SkTo
>
> Change-Id: I8de790d5013db2105ad885fa2683303d7c250b09
> Reviewed-on: https://skia-review.googlesource.com/133620
> Reviewed-by: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,halcanary@google.com
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Iafd738aedfb679a23c061a51afe4b98a8d4cdfae
Reviewed-on: https://skia-review.googlesource.com/134504
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Bug: skia:7994
Change-Id: I83bb309a2c8fb0bddaf78ba32c0a07537e483900
Reviewed-on: https://skia-review.googlesource.com/129648
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Mike Klein <mtklein@google.com>
Bug: skia:
Change-Id: Ide917f54633370f1fce46a115fa923794b981e2e
Reviewed-on: https://skia-review.googlesource.com/129461
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Reed <reed@google.com>
This was triggered by an exploit that started the first
edge well outside the final rectangle, causing the captured
to exceed the correct result.
Ivan observes that we really only want the first and third
corners to compute the bounds, so remove the tracking code
that looks for a valid range of points, and record the
corners instead.
R=robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: If228573d0f05c7158dba8142c144d13834e691ec
Reviewed-on: https://skia-review.googlesource.com/122081
Commit-Queue: Cary Clark <caryclark@skia.org>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Auto-Submit: Cary Clark <caryclark@skia.org>
One of the path is rect bug fixes changed
the behavior of zero-length strokes which
showed up as a change in Gold.
The bug is if a rect is defined by a
series of colinear movetos, the bounds
did not work out if the rect started
and stopped in the middle of a side.
R=robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: I226545efeda03dedd928eebc120d2508b428fef0
Reviewed-on: https://skia-review.googlesource.com/122002
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Cary Clark <caryclark@skia.org>
Removed a test that appeared to go uncalled;
Ivan to the rescue, with a test case
proving that it is required.
R=robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: I7df9688072bd36b7597673148e3fe5dbbf82f5a7
Reviewed-on: https://skia-review.googlesource.com/121883
Commit-Queue: Cary Clark <caryclark@skia.org>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Exposes that final close along a diagonal need not
include a close verb if the subsequent verb is move;
so we have to check for a diagonal then.
The later check for diagonal included a comment that
it may not be needed which does appear to be the case.
R=robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: I17a9414e8b3e69b82c2eda28195696eae4e3d513
Reviewed-on: https://skia-review.googlesource.com/121801
Commit-Queue: Cary Clark <caryclark@skia.org>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This one accumulates the othershoot when all four sides
have the same direction, and the final side when closed
should cause the overshoot to be ignored.
Docs-Preview: https://skia.org/?cl=121787
Bug: 824145,skia:7792
Change-Id: I71ea0fcdd0f03a4fcac224b57220c65c321112f6
Reviewed-on: https://skia-review.googlesource.com/121787
Commit-Queue: Cary Clark <caryclark@skia.org>
Commit-Queue: Robert Phillips <robertphillips@google.com>
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
This is bug number ten in the series, and is the
most interesting. It exploits that the code tracks
corners 0, 2, and 3 but not corner 1.
Changing the code to track all corners is the biggest
so far, and while it (hopefully) simplifies things,
the presence of new code may signify more bugs to come.
R=robertphillips@google.com
Bug: 824145,skia::7792
Change-Id: Ia18e4d80fbed06ae6d9c89dcb4c462c5610213cc
Reviewed-on: https://skia-review.googlesource.com/121487
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
This variation exploits a sequence which uses a zero
length line to note that lines have been recorded, but
no rectangle edge has been encountered.
R=robertphillips@google.com
Docs-Preview: https://skia.org/?cl=121282
Bug: 824145,skia:7792
Change-Id: I652e9482b2867c3d7da30d5f5df2aecbfd0d716d
Reviewed-on: https://skia-review.googlesource.com/121282
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Cary Clark <caryclark@skia.org>
This variation tricks SkPath::isRect by exploiting
that the implementation resets the point pointer to
process the close verb, and using the reset pointer
to walk over a series of points that don't move.
In addition to fixing this, rename variables to
make the line creation more obvious, since left,
right, and friends, are not the left and right.
R=robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: If8ebbc3eedd270652670d6e111a5bc02e61f0eec
Reviewed-on: https://skia-review.googlesource.com/121122
Reviewed-by: Robert Phillips <robertphillips@google.com>
Commit-Queue: Cary Clark <caryclark@skia.org>
This addresses comment #17 of skbug.com/7792.
The bug overshoots the end and exploits that the
first point tracked by close isn't the first
point in the rectangle.
Fixing this slightly regresses the example
in comment #14; before it was treated as a filled
rect but now it is not; this conservative approach
doesn't cause any other regressions.
bug7792 in pathfill.cpp verifies that all paths
in the bug draw correctly by comparing CPU and GPU.
R=robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: I55bea023d2ad7456c8c3ebd9d1df95fe34e0a0d4
Reviewed-on: https://skia-review.googlesource.com/120996
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
More edge cases found; clean up the logic a bit
to make more clear where the rectangle points
start and stop.
R=robertphillips@google.com,brianosman@google.com
Bug: 824145,skia:7792
Change-Id: Ie24dfd1519f30875f44ffac68e20d777490b00b9
Reviewed-on: https://skia-review.googlesource.com/120422
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Add a check to see that the close path generated line
is horizontal or vertical when determining that path
is a rect.
Also change several tests to defer their initialization
to reduce debugging interference.
R=brianosman@google.com,robertphillips@google.com
Bug: 824145,skia:7792
Change-Id: I4a081ee4ffd3558b499a7a1aede2d6232059715e
Reviewed-on: https://skia-review.googlesource.com/120081
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
R=brianosman@google.com,robertphillips@google.com
TBR=reed@google.com
Bug: 824145,skia:7792
Change-Id: I24f121cfa7d437c95b94bd917d3c4888a10c519e
Reviewed-on: https://skia-review.googlesource.com/119569
Commit-Queue: Cary Clark <caryclark@skia.org>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
New format should be much simpler:
- only store public data (e.g. points, verbs, filltype)
- deserialize just uses public APIs
Refactor reading code to manage different (older) versions, to make
it clear (hopefully) what we can delete when we can abandon version
3 support.
Bug: skia:
Change-Id: I30465f891cba3f044ae1cb2c13c04f04fdc9da78
Reviewed-on: https://skia-review.googlesource.com/109160
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
Remove REPORTER_ASSERT_MESSAGE.
Change-Id: I6d00715901159c93e22d182fe24aac92b5fdbcf4
Reviewed-on: https://skia-review.googlesource.com/100361
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Make insetting greater than width or height collapse to a point/line.
SkPath::addRRect() doesn't ignore an empty SkRRect.
Change-Id: I933a3419a6d75be534f1d8328faa715772045f67
Reviewed-on: https://skia-review.googlesource.com/85680
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
This reverts commit c382384848.
Reason for revert: need to add legacy flag to chrome first
Original change's description:
> keep SVG arcs axis aligned
>
> Computing the arc width introduces rounding errors that cause the
> arc to exceed 1/4 circle and cause integer anchored arcs to start
> outside their marks. A round rect may lose convexity as a result.
>
> Check if arcTo() inputs are integers and arc is 90 degrees;
> if so, output conics which are axis-aligned on integers as well.
>
> This is triggered when using SVG to represent a round rect.
>
> Possible future enhancements are recorded in bug.skia.org/7383
>
> R=reed@google.com,djsollen@google.com
> Change-Id: I6609456fcefabcda6c9560a044533ecb5cda2d31
> Reviewed-on: https://skia-review.googlesource.com/79423
> Reviewed-by: Derek Sollenberger <djsollen@google.com>
> Commit-Queue: Derek Sollenberger <djsollen@google.com>
TBR=djsollen@google.com,caryclark@google.com,reed@google.com,caryclark@skia.org
Change-Id: Ia503ea62def15322df2b11da30d377a9543d6999
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/81281
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
Computing the arc width introduces rounding errors that cause the
arc to exceed 1/4 circle and cause integer anchored arcs to start
outside their marks. A round rect may lose convexity as a result.
Check if arcTo() inputs are integers and arc is 90 degrees;
if so, output conics which are axis-aligned on integers as well.
This is triggered when using SVG to represent a round rect.
Possible future enhancements are recorded in bug.skia.org/7383
R=reed@google.com,djsollen@google.com
Change-Id: I6609456fcefabcda6c9560a044533ecb5cda2d31
Reviewed-on: https://skia-review.googlesource.com/79423
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Derek Sollenberger <djsollen@google.com>
The added unit test shows that we'll trigger SkASSERT failure if we
forgot to check that the edges are lines (instead of quads or cubics).
Similar to skia:7015, this bug is not triggered in our production
because we don't use DAA for convex paths by default. The skipRect is
an optimization just for convex paths.
Bug: skia:7051
Change-Id: Id87ce2d452ede0db9a48425541f473af19ee0572
Reviewed-on: https://skia-review.googlesource.com/48045
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This reverts commit f953523224.
Reason for revert: Re-landing now that gold has settled.
Original change's description:
> Revert "Don't ignore degenerates when deciding if a path is convex"
>
> This reverts commit 53cd6c4331.
>
> Reason for revert: Temporary to limit gold cross-talk with other CLs.
>
> Original change's description:
> > Don't ignore degenerates when deciding if a path is convex
> >
> > This ensures that a path with a second contour will always be marked
> > concave. GrDefaultPathRenderer was incorrectly drawing paths of this type
> > (thinking that it could fill them with simple triangulation).
> >
> > Bug: skia:7020 skia:1460
> > Change-Id: I62bfd72e4c61da427687acf53c552357b57707aa
> > Reviewed-on: https://skia-review.googlesource.com/47082
> > Reviewed-by: Cary Clark <caryclark@google.com>
> > Commit-Queue: Brian Osman <brianosman@google.com>
>
> TBR=bsalomon@google.com,brianosman@google.com,caryclark@google.com,reed@google.com
>
> Change-Id: Id7d121633faeb8a43dbd334409408ba51db43d68
> No-Presubmit: true
> No-Tree-Checks: true
> No-Try: true
> Bug: skia:7020 skia:1460
> Reviewed-on: https://skia-review.googlesource.com/47343
> Reviewed-by: Brian Osman <brianosman@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=bsalomon@google.com,brianosman@google.com,caryclark@google.com,reed@google.com
# Not skipping CQ checks because original CL landed > 1 day ago.
Bug: skia:7020 skia:1460
Change-Id: I45ff90a54b66ce9ea068f246d066cc24b310c966
Reviewed-on: https://skia-review.googlesource.com/47820
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This reverts commit 53cd6c4331.
Reason for revert: Temporary to limit gold cross-talk with other CLs.
Original change's description:
> Don't ignore degenerates when deciding if a path is convex
>
> This ensures that a path with a second contour will always be marked
> concave. GrDefaultPathRenderer was incorrectly drawing paths of this type
> (thinking that it could fill them with simple triangulation).
>
> Bug: skia:7020 skia:1460
> Change-Id: I62bfd72e4c61da427687acf53c552357b57707aa
> Reviewed-on: https://skia-review.googlesource.com/47082
> Reviewed-by: Cary Clark <caryclark@google.com>
> Commit-Queue: Brian Osman <brianosman@google.com>
TBR=bsalomon@google.com,brianosman@google.com,caryclark@google.com,reed@google.com
Change-Id: Id7d121633faeb8a43dbd334409408ba51db43d68
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: skia:7020 skia:1460
Reviewed-on: https://skia-review.googlesource.com/47343
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This ensures that a path with a second contour will always be marked
concave. GrDefaultPathRenderer was incorrectly drawing paths of this type
(thinking that it could fill them with simple triangulation).
Bug: skia:7020 skia:1460
Change-Id: I62bfd72e4c61da427687acf53c552357b57707aa
Reviewed-on: https://skia-review.googlesource.com/47082
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Added a unit test too.
BUG=chromium:756563
Change-Id: Ic77a89b4a98d1a553877af9807a3d3bdcd077bb9
Reviewed-on: https://skia-review.googlesource.com/44420
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Reed <reed@google.com>
As DAA does not chop edges at Y extrema, it's valid for convex edges to
have only one edge (e.g., a single cubic edge with the valley shape \_/).
This wasn't an issue for production because DAA is never called for
convex paths by default.
Bug=skia:7015
Change-Id: Iac79801d6a24188970ef6f7bf723494a25d92a1e
Reviewed-on: https://skia-review.googlesource.com/42942
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
The newlines got accidentally converted to CRLF in
https://skia-review.googlesource.com/c/skia/+/39521
This CL simply runs dos2unix to convert them back.
There are probably more files affected by 39521, but
these 3 files are the major ones that got thousands
of newlines converted.
Bug: skia:
Change-Id: I0aab5c9e2ab3d491bfe746d6b2db19532a89d654
Reviewed-on: https://skia-review.googlesource.com/42921
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
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>
The tiny path added to PathTest.cpp has
tinier cross products (e.g. 1e-12)
so appears to be a series of unbending
lines as far as getConvexity is concerned.
This point fix looks for paths that
do not bend left or right or go backwards,
but do have a bounds, and calls them
concave.
A better fix may be to consider empty
and degenerate paths to be concave
instead of convex; I don't know if
anyone relies on the existing behavior.
Another better fix may be to change
the math to compute the path turns
even though the numbers are very small;
on the surface, very difficult.
R=bsalomon@google.com,reed@google.com
Bug:755839
Change-Id: Ie2280f3f0b95fecab2899f5fc579fd39258e0647
Reviewed-on: https://skia-review.googlesource.com/38720
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
We use SK_SUPPORT_LEGACY_DELTA_AA to guard the golden image change.
Such flag is defined for Android, Chrome, and Google3 so our auto-rollers
should all be OK.
TBR: bungeman@google.com
Bug: skia:6947
Change-Id: Ic2705e82f4f7f15ec08499254dce75b93d41727e
Reviewed-on: https://skia-review.googlesource.com/33762
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
We only need to clip a temporary x to ensure that we don't blit
beyond clip. Storing such clipped x is problematic because it
may make our edges unsorted.
The added unit test would fail without this fix.
Bug: skia:6947
Change-Id: I6c21d7c7c097e50fef18ab151921d6c07c089318
Reviewed-on: https://skia-review.googlesource.com/33420
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Ben Wagner <bungeman@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>
This reverts commit df6660f64e.
Reason for revert: crashing dm on android and windows
Original change's description:
> 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.
>
> Change-Id: I40e8db87e4f61abb23217281ab0365c6af222fa3
> Reviewed-on: https://skia-review.googlesource.com/24802
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Mike Reed <reed@google.com>
TBR=bungeman@google.com,reed@google.com,enne@chromium.org
Change-Id: I06fa89c05b785652b097ae04e7ebc001a7c176b2
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/26944
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
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.
Change-Id: I40e8db87e4f61abb23217281ab0365c6af222fa3
Reviewed-on: https://skia-review.googlesource.com/24802
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Mike Reed <reed@google.com>
Previosly, SkSize had a base class, which prevented it.
Also removes unused SkISize::clampNegToZero() and
SkSize::clampNegToZero().
Change-Id: I7b93b42f6f6381c66e294bbedee99ad53c6c3436
Reviewed-on: https://skia-review.googlesource.com/13187
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
This silences a new warning in clang 5.0
Change-Id: Ieb5b75a6ffed60107c3fd16075d2ecfd515b55e8
Reviewed-on: https://skia-review.googlesource.com/10006
Commit-Queue: Brian Salomon <bsalomon@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
not sure about api -- perhaps it could just return the bounds, and make them 0,0,0,0 if the path
is empty -- the caller can trivially know if the path is empty themselves.
BUG=skia:
Change-Id: I2dbb861e8d981b27c5a6833643977f5bd6802217
Reviewed-on: https://skia-review.googlesource.com/7989
Reviewed-by: Cary Clark <caryclark@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Mike Reed <reed@google.com>
* SkAutoFree moved to SkTemplates.h (now implmented with unique_ptr).
* SkAutoMalloc and SkAutoSMalloc moved to SkAutoMalloc.h
* "SkAutoFree X(sk_malloc_throw(N));" --> "SkAutoMalloc X(N);"
Revert "Revert 'SkTypes.h : move SkAutoMalloc into SkAutoMalloc.h'"
This reverts commit c456b73fef.
Change-Id: Ie2c1a17c20134b8ceab85a68b3ae3e61c24fbaab
Reviewed-on: https://skia-review.googlesource.com/6886
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
* SkAutoFree moved to SkTemplates.h (now implmented with unique_ptr).
* SkAutoMalloc and SkAutoSMalloc moved to SkAutoMalloc.h
* "SkAutoFree X(sk_malloc_throw(N));" --> "SkAutoMalloc X(N);"
Change-Id: Idacd86ca09e22bf092422228599ae0d9bedded88
Reviewed-on: https://skia-review.googlesource.com/4543
Reviewed-by: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
SkPath::dump() and SkPath::dumpHex() dump the fill type
in addition to the data so that the original path can
be faithfully reconstructed.
This may be a small part of why some error cases
aren't reproduced.
R=reed@google.com
BUG=skia:6041
Change-Id: Ice86bf08ea907a6b87ceef182a9316a3c979af0b
Reviewed-on: https://skia-review.googlesource.com/6185
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Cary Clark <caryclark@google.com>
Previously, we forgot to use AdditiveBlitter in two places where partial
rows are blitterred. That causes SkAAClip to complain as in skia:6003.
BUG=skia:6003
Change-Id: I4f4a896072448bdb3f287a2eb61cb64b1256ea78
Reviewed-on: https://skia-review.googlesource.com/5273
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
If we use the oldy and dy directly as we did previously, the slope could
be very different from (newSnappedX - fSnappedX) / (newSnappedY -
fSnappedY) in the updateLine when the edge made a lot of updates with
small dy but large dx. That will cause bug skia:5995
BUG=skia:5995
Change-Id: If521976ed87195dfea5961afd58bedb98447c568
Reviewed-on: https://skia-review.googlesource.com/5269
Reviewed-by: Cary Clark <caryclark@google.com>
Commit-Queue: Yuqian Li <liyuqian@google.com>
This reverts commit dd13c02079.
Reason for revert: this breaks the Chromium DEPS roll as we break the layout_tests. I'll add a flag to guard the change in the future and enable the flag while change the layout_tests.
Original change's description:
> Add the missing shift to the dy
>
> BUG=chromium:668907
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5266
>
> Change-Id: I6d3e56ffc149fbeac6f7a2df740542abbf84dac8
> Reviewed-on: https://skia-review.googlesource.com/5266
> Reviewed-by: Cary Clark <caryclark@google.com>
> Commit-Queue: Yuqian Li <liyuqian@google.com>
>
TBR=mtklein@chromium.org,caryclark@google.com,liyuqian@google.com,reed@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Ifd5aa50f155c3ebe2f1495cbf3b8dd706211a639
Reviewed-on: https://skia-review.googlesource.com/5286
Commit-Queue: Yuqian Li <liyuqian@google.com>
Reviewed-by: Yuqian Li <liyuqian@google.com>
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
