$ 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
