We're currently decrementing early in checkForDeferredSave(), but that
means we break the getSaveCount() invariant during willSave() dispatch.
Instead, we can defer to doSave(), until after willSave() is called.
This allows overriders to call getSaveCount().
R=reed@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/1113603002
The Google style guide states that only one of {virtual,override,final}
should be used for each declaration, since override implies virtual and
final implies both virtual and override.
The entries were found using the following command line:
$ find src/ -iname "*.h" -o -iname "*.cpp" | xargs pcregrep -M
"[^\n/]+virtual\ [^;{]+\ [a-zA-Z0-9_]+\([^;{]+\ override[ \n]*[;{]"
The regex was a courtesy of nick@chromium.org
BUG=None
R=mtklein@google.com
Review URL: https://codereview.chromium.org/1110013002
Reason for revert:
MIPS
Original issue's description:
> De-proc Color32
>
> Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
> which is no longer needed.
>
> Seems handy to have SkTypes include the relevant intrinsics when
> we know we've got them, but I'm not married to it.
>
> Locally this looks like a pointlessly small perf win, but I'm mostly
> keen to get all the code together.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/376e9bc206b69d9190f38dfebb132a8769bbd72bTBR=reed@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1108163002
Also strips SK_SUPPORT_LEGACY_COLOR32_MATH,
which is no longer needed.
Seems handy to have SkTypes include the relevant intrinsics when
we know we've got them, but I'm not married to it.
Locally this looks like a pointlessly small perf win, but I'm mostly
keen to get all the code together.
BUG=skia:
Review URL: https://codereview.chromium.org/1104183004
patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs
On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Mac10.8-Clang-Arm7-Debug-Android-Trybot,Build-Ubuntu-GCC-Arm7-Release-Android_NoNeon-Trybot
Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ec
Review URL: https://codereview.chromium.org/1109643002
Reason for revert:
compile failures.
Original issue's description:
> Mike's radial gradient CL with better float -> int.
>
> patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
>
> This looks quite launchable. radial_gradient3, min of 100 samples:
> N5: 985µs -> 946µs
> MBP: 395µs -> 279µs
>
> On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
>
> BUG=skia:
>
> CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
>
> Committed: https://skia.googlesource.com/skia/+/abf6c5cf95e921fae59efb487480e5b5081cf0ecTBR=reed@google.com,robertphillips@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1109883003
patch from issue 1072303005 at patchset 40001 (http://crrev.com/1072303005#ps40001)
This looks quite launchable. radial_gradient3, min of 100 samples:
N5: 985µs -> 946µs
MBP: 395µs -> 279µs
On my MBP, most of the meat looks like it's now in reading the cache and writing to dst one color at a time. Is that something we could do in float math rather than with a lookup table?
BUG=skia:
CQ_EXTRA_TRYBOTS=client.skia.android:Test-Android-GCC-Nexus5-CPU-NEON-Arm7-Debug-Trybot,Test-Android-GCC-Nexus9-CPU-Denver-Arm64-Debug-Trybot
Review URL: https://codereview.chromium.org/1109643002
This may be a small help to slimming paint:
picture_overhead_draw 1.25us -> 1.22us 0.98x
picture_overhead_nodraw 318ns -> 276ns 0.87x
It certainly cannot hurt performance.
BUG=chromium:470553
TBR=reed@google.com
No public API changes.
Review URL: https://codereview.chromium.org/1098183003
This saves "up to" 22 bytes per SkPicture.
Due to alignment, this reduces sizeof(SkPicture):
- from 88 to 72 bytes on Linux x64
- from 68 to 48 bytes on Android
(with Chrome's build settings)
It also somewhat simplifies the GPU veto logic.
BUG=skia:
[mtklein] No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1060863004
The Google style guide states that only one of {virtual,override,final}
should be used for each declaration, since override implies virtual and
final implies both virtual and override.
The entries were found using the following command line:
$ find src/ -iname "*.h" -o -iname "*.cpp" | xargs pcregrep -M
"[^\n/]+virtual\ [^;{]+\ [a-zA-Z0-9_]+\([^;{]+\ override[ \n]*[;{]"
The regex was a courtesy of nick@chromium.org
BUG=None
R=mtklein@google.com
NOPRESUBMIT=true
Review URL: https://codereview.chromium.org/1086143003
Move line dashing logic from GrContext::drawPath to
GrDashLinePathRenderer. This makes it possible to let path renderers render arbitrary dashed paths.
End goal is to implement dashing in GrStencilAndCoverPathRenderer.
Review URL: https://codereview.chromium.org/1100073003
The Google style guide states that only one of {virtual,override,final}
should be used for each declaration, since override implies virtual
and final implies both virtual and override.
The entries were found using the following command line:
$ find src/utils -iname "*.h" -o -iname "*.cpp" | xargs pcregrep -M
"[^\n/]+virtual\ [^;{]+\ [a-zA-Z0-9_]+\([^;{]+\ override[ \n]*[;{]"
The regex was a courtesy of nick@chromium.org
BUG=None
R=mtklein@google.com
Review URL: https://codereview.chromium.org/1099333004
The Google style guide states that only one of {virtual,override,final}
should be used for each declaration, since override implies virtual and
final implies both virtual and override.
The entries were found using the following command line:
$ find src/fonts -iname "*.h" -o -iname "*.cpp" | xargs pcregrep -M
"[^\n/]+virtual\ [^;{]+\ [a-zA-Z0-9_]+\([^;{]+\ override[ \n]*[;{]"
The regex was a courtesy of nick@chromium.org
BUG=None
R=mtklein@google.com
Review URL: https://codereview.chromium.org/1101343002
The Google style guide states that only one of {virtual,override,final}
should be used for each declaration, since override implies virtual and
final implies both virtual and override.
The entries were found using the following command line:
$ find src/pipe -iname "*.h" -or -iname "*.cpp" | xargs pcregrep -M
"[^\n/]+virtual\ [^;{]+\ [a-zA-Z0-9_]+\([^;{]+\ override[ \n]*[;{]"
The regex was a courtesy of nick@chromium.org
BUG=None
R=mtklein@google.com
Review URL: https://codereview.chromium.org/1104863003
