This turns out to be mostly deleting dead debugging code.
Change-Id: I4969ea380e6125e8b557d430c6720edc0a337a79
Reviewed-on: https://skia-review.googlesource.com/c/174284
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@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 0fb1ee98cf.
Reason for revert: looks like this increased size by ~8K.
Original change's description:
> replace SkNVRefCnt with SkRefCnt
>
> SkNVRefCnt trades a small amount of code size (vtable) and runtime
> (vptr) memory usage for a larger amount of code size (templating). It
> was written back in a time when all we were really thinking about was
> runtime memory usage, so I'm curious to see where performance, code
> size, and memory usage all move if it's removed.
>
> Looking at the types I've changed here, my guess is that performance and
> memory usage will be basically unchanged, and that code size will drop a
> bit. Nothing else it's nicer to have only one ref-counting base class.
>
> Change-Id: I7d56a2b9e2b9fb000ff97792159ea1ff4f5e6f13
> Reviewed-on: https://skia-review.googlesource.com/c/166203
> Reviewed-by: Brian Salomon <bsalomon@google.com>
> Commit-Queue: Mike Klein <mtklein@google.com>
TBR=mtklein@google.com,bsalomon@google.com,mtklein@chromium.org
Change-Id: Ibcfcc4b523c466a535bea5ffa30d0fe2574c5bd7
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://skia-review.googlesource.com/c/166360
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
SkNVRefCnt trades a small amount of code size (vtable) and runtime
(vptr) memory usage for a larger amount of code size (templating). It
was written back in a time when all we were really thinking about was
runtime memory usage, so I'm curious to see where performance, code
size, and memory usage all move if it's removed.
Looking at the types I've changed here, my guess is that performance and
memory usage will be basically unchanged, and that code size will drop a
bit. Nothing else it's nicer to have only one ref-counting base class.
Change-Id: I7d56a2b9e2b9fb000ff97792159ea1ff4f5e6f13
Reviewed-on: https://skia-review.googlesource.com/c/166203
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
PS1 reverts commit 6c8d242b14.
PS2 uses an SkMutex for thread safety.
Change-Id: I9318f92cc028844b3dc5a99a00282c2762057895
Reviewed-on: https://skia-review.googlesource.com/155060
Reviewed-by: Mike Klein <mtklein@google.com>
Make the listner list for bitmas and paths use a simple atomic
stack. This stack implementation does not have the ABA problem
because you can only pop the entire stack at once
with exchange(nullptr).
BUG=skia:8324
Change-Id: I7b0438a42c473b36cd4b0cbf236bf1692c5afab3
Reviewed-on: https://skia-review.googlesource.com/154861
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Herb Derby <herb@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>
This typedef was created at a time when compilers often used sizeof(int)
storage for a bool. This is no longer the case and in all compilers
currently supported 'sizeof(bool) == 1'. Removing this also revealed one
field which was actually not a bool but a tri-state enum.
Change-Id: I9240ba457335ee3eff094d6d3f2520c1adf16960
Reviewed-on: https://skia-review.googlesource.com/134420
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Spun off from the SkTFitsIn CL.
Change-Id: I686d680df6a36ebc02db3847ad5e2cedcbcd67ef
Reviewed-on: https://skia-review.googlesource.com/134083
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Ib3e2661d0383bf154bc9178dac070dfd910a393c
Reviewed-on: https://skia-review.googlesource.com/115200
Reviewed-by: Mike Klein <mtklein@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Bug: skia:7604
Change-Id: I508bbdc006e1c6edce2006be0c43b037038c876b
Reviewed-on: https://skia-review.googlesource.com/108360
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
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>
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>
That GM has a path with 16k points, arranged in a rectangle. When we try
to draw it in Ganesh, we first check to see if it's a (closed) rectangle.
We eventually decide that it is a rectangle, but not closed, so it gets
passed along. Then we construct a GrShape, which tries to simplify the
shape, again asking if it's a rectangle...
Each isRect query was iterating over the 16k verbs, and for each one,
calling atVerb(i). That, internally, calls verbs(), which calls validate()
in debug builds. So we were walking all 16k points 16k times (to ensure
the bounds were correct). The end result is that the GM took over 11
seconds to draw, and now takes 3 ms.
Bug: skia:
Change-Id: If5f7a067b8c25f049dc64275d94a42ae4a50f6a9
Reviewed-on: https://skia-review.googlesource.com/34723
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@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>
Note that this does not clean up the users of this function, which
may themselves be subject to other overflow issues.
BUG=chromium:728936
Change-Id: I3eaa7627c3b6ff49296ea2618a0157dacdc1d9cc
Reviewed-on: https://skia-review.googlesource.com/29121
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
