Commit Graph

1101 Commits

Author SHA1 Message Date
reed
7da19014fd use Sk4f for matrix math
Need to land SK_SUPPORT_LEGACY_SCALAR_MAPPOINTS in chrome to suppress Affine
version which causes slight differences (which will need to be rebaselined)

BUG=skia:

Review URL: https://codereview.chromium.org/1045493002
2015-03-29 11:58:48 -07:00
reed
d8b34c26c2 use table of procs (and unrolling) to speed up mapPts
BUG=skia:

Review URL: https://codereview.chromium.org/1040783002
2015-03-27 14:00:41 -07:00
tomhudson
573ae01295 Move HWUI boilerplate into utils/android
Duplicate code from the HWUI backends for DM and nanobench
moves into a single place, saving a hundred lines or more of
cut-and-paste.

There's some indication that this increases the incidence of
SkCanvas "Unable to find device for layer." warnings, but no
clear degradation in test results.

R=djsollen@google.com,mtklein@google.com
BUG=skia:3589

Review URL: https://codereview.chromium.org/1036303002
2015-03-27 12:22:01 -07:00
tomhudson
75a0ebb0d0 Minor cleanup in nanobench
Simplify time() by removing conditionals; reduce the amount of
parameter passing.
Add a convenience function to Target.

R=mtklein@google.com
BUG=skia:3595

Review URL: https://codereview.chromium.org/1039253002
2015-03-27 12:11:44 -07:00
robertphillips
1d24b8dfe9 Add matrix constructing helpers to SkMatrix
Review URL: https://codereview.chromium.org/1034273002
2015-03-26 19:57:08 -07:00
mtklein
3d4c4a5a9f SkPMFloat::trunc()
Add and test trunc(), which is what get() used to be before rounding.
Using trunc() is a ~40% speedup on our linear gradient bench.

#neon #floats
BUG=skia:3592
#n5
#n9
CQ_INCLUDE_TRYBOTS=client.skia.android:Test-Android-Nexus5-Adreno330-Arm7-Debug-Trybot;client.skia.android:Test-Android-Nexus9-TegraK1-Arm64-Release-Trybot

Review URL: https://codereview.chromium.org/1032243002
2015-03-26 12:32:29 -07:00
tomhudson
d968a6f29e Android HWUI backend Nanobench
Uses filtering canvas from utils/android, shared with DM.
Follow-up plans in https://skbug.com/3589, https://skbug.com/3595

R=djsollen@google.com

Review URL: https://codereview.chromium.org/1029423010
2015-03-26 11:28:06 -07:00
joshualitt
e0b19d4985 small fix for nanobench segfault when not running any tests
BUG=skia:

Review URL: https://codereview.chromium.org/1030353004
2015-03-26 10:41:02 -07:00
reed
5501103881 use new faster/vector impl for chopping conics
BUG=skia:

Review URL: https://codereview.chromium.org/1035943002
2015-03-26 09:10:22 -07:00
reed
c08330f160 remove slower scalar code in favor of vectors
BUG=skia:

Review URL: https://codereview.chromium.org/1001833006
2015-03-26 07:26:08 -07:00
mtklein
36352bf5e3 C++11 override should now be supported by all of {bots,Chrome,Android,Mozilla}
NOPRESUBMIT=true

BUG=skia:
DOCS_PREVIEW= https://skia.org/?cl=1037793002

Review URL: https://codereview.chromium.org/1037793002
2015-03-25 18:17:32 -07:00
mtklein
02fd592c8d hack on linear gradient
Am I going nuts or can we get this down to just adds and converts in the loop?

#floats #n9
BUG=skia:3592
CQ_INCLUDE_TRYBOTS=client.skia.android:Test-Android-Nexus9-TegraK1-Arm64-Release-Trybot

Review URL: https://codereview.chromium.org/1008973004
2015-03-25 18:13:02 -07:00
reed
b25a83bd88 Use Sk4x to speed-up bounds of an array of points
BUG=skia:

Review URL: https://codereview.chromium.org/1015633004
2015-03-25 14:30:49 -07:00
mtklein
15391ee4ac Update 4-at-a-time APIs.
There is no reason to require the 4 SkPMFloats (registers) to be adjacent.
The only potential win in loads and stores comes from the SkPMColors being adjacent.

Makes no difference to existing bench.

BUG=skia:

Review URL: https://codereview.chromium.org/1035583002
2015-03-25 13:43:34 -07:00
reed
6b9ef90c02 SkChopCubicAt2 using Sk2s -- 2x faster
BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/1036753002
2015-03-24 19:24:34 -07:00
reed
8010632f24 remove meaningless matrix benches, add mapPts() and add new benches
mapPts definitely faster than mapPoints (identity and perspective same speed). Up to 3x for large values of N.

cloned from https://codereview.chromium.org/1031443002/

BUG=skia:

Review URL: https://codereview.chromium.org/1030653002
2015-03-23 08:15:14 -07:00
tomhudson
c589f6c968 Get rid of excess cleverness in benchmark
RotatedRectBench was asking for its base layer size, which may
not be what it expects with odd canvas modes (particularly proxies).
Most benchmarks are not so sophisticated; they hard-wire their
size and just use that (expected) value.

R=mtklein@google.com,djsollen@google.com
BUG=skia:3566

Review URL: https://codereview.chromium.org/1015013004
2015-03-23 07:46:13 -07:00
reed
b640203cd5 use Sk2s for conics
BUG=skia:

Review URL: https://codereview.chromium.org/1025033002
2015-03-20 13:23:43 -07:00
egdaniel
9a0f629973 Only use 256x256 tiles on hd2000 nanobench bots
Initial experiments did show that the 256 tile size fixed the hd2000 win7
nanobot failures. However it did not have any effect on other bots, so this
change is to move back to the larger tile size on all bots expect for the
hd2000.

BUG=skia:

Review URL: https://codereview.chromium.org/1022083002
2015-03-20 07:03:52 -07:00
reed
40b7dd57ef use Sk2s for EvalQuadTangent and ChopQuadAt
cloned from https://codereview.chromium.org/1026633002/

BUG=skia:

Review URL: https://codereview.chromium.org/1024873003
2015-03-20 06:01:08 -07:00
egdaniel
5d09568a0c Move skp nanobench tile size back to 256x256 to see if it fixes nanobench crashes
Going back to old nanobench tile size to see if the increase to tile is what has been
causing recent nanobench crashes. The crashes seem very nondeterministic and hard to
debug manually.

256x256 is too small of a tile to give accurate gpu results but if this fixes we can try some compromise in the middle

BUG=skia:

Review URL: https://codereview.chromium.org/1022823003
2015-03-19 11:00:09 -07:00
reed
65cb2cd2f7 alt SkEvalQuadAt that returns its answer, using Sk2f
BUG=skia:

Review URL: https://codereview.chromium.org/1011493003
2015-03-19 10:18:47 -07:00
reed
effcba4a4d Revert of replace SkFixedDiv impl with native 64bit math (patchset #2 id:20001 of https://codereview.chromium.org/1022543003/)
Reason for revert:
http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/53096

layouttests failures

Original issue's description:
> replace SkFixedDiv impl with native 64bit math
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/7c44ca926bf42b3b2e56131f250c0fd58f87ac71

TBR=
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/1018523008
2015-03-19 04:10:42 -07:00
reed
7c44ca926b replace SkFixedDiv impl with native 64bit math
BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/1022543003
2015-03-18 19:04:43 -07:00
senorblanco
24e06d5244 Remove uniqueID from all filter serialization.
(This is essentially a revert of https://codereview.chromium.org/503833002/.)

This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs.

Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.)

BUG=skia:

Review URL: https://codereview.chromium.org/1019493002
2015-03-18 12:11:33 -07:00
reed
93a1215fe0 SkPaint::FilterLevel -> SkFilterQuality
clone (+rebase) of https://codereview.chromium.org/1009183002/

BUG=skia:
TBR=scroggo@google.com

Review URL: https://codereview.chromium.org/1014533004
2015-03-16 10:08:34 -07:00
mtklein
95553d917c DM: display current memory usage (instead of peak) when available.
Seems strictly more useful.

This implements Mac and Windows, which seemed easy.  Don't know how to do this on Linux yet.

BUG=skia:

CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.9-MacMini6.2-HD4000-x86_64-Debug-Trybot

NOTREECHECKS=true
TBR=halcanary@google.com

Review URL: https://codereview.chromium.org/990723002
2015-03-12 08:24:21 -07:00
bsalomon
cc4d6673a9 Increase default tile sizes in nanobench
R=mtklein@google.com

Review URL: https://codereview.chromium.org/982863003
2015-03-05 13:42:27 -08:00
mtklein
548bf38b28 4-at-a-time SkPMColor -> SkPMFloat API.
Please see if this looks usable.  It may even give a perf boost if you use it, even without custom implementations for each instruction set.

I've been trying this morning to beat this naive loop implementation, but so far no luck with either _SSE2.h or _SSSE3.h.  It's possible this is an artifact of the microbenchmark, because we're not doing anything between the conversions.  I'd like to see how this fits into real code, what assembly's generated, what the hot spots are, etc.

I've updated the tests to test these new APIs, and splintered off a pair of new benchmarks that use the new APIs.  This required some minor rejiggering in the benches.

BUG=skia:

Review URL: https://codereview.chromium.org/978213003
2015-03-05 11:31:59 -08:00
mtklein
4e644f5d50 Update SkPMFloat API a bit.
Instead of set(SkPMColor), add a constructor SkPMFloat(SkPMColor).
Replace setA(), setR(), etc. with a 4 float constructor.

And, promise to stick to SkPMColor order.

BUG=skia:

Review URL: https://codereview.chromium.org/977773002
2015-03-04 11:25:27 -08:00
mtklein
60ff4582ae Trim the fat off SkPMFloat bench.
This bench was ~75% overhead, ~25% good bench.  It is now just about the
opposite: about 30% of the runtime is loop and random number overhead, and
about 70% of the time is spent doing SkPMColor <-> SkPMFloat work.

BUG=skia:

NOPRESUBMIT=true

Review URL: https://codereview.chromium.org/968133005
2015-03-03 08:03:27 -08:00
reed
7eeba25877 Notify resource caches when pixelref genID goes stale
patch from issue 954443002 at patchset 40001 (http://crrev.com/954443002#ps40001)

BUG=skia:

Review URL: https://codereview.chromium.org/950363002
2015-02-24 13:54:23 -08:00
mtklein
a2f4be76a9 Sketch SkPMFloat
BUG=skia:

Committed: https://skia.googlesource.com/skia/+/50d2b3114b3e59dc84811881591bf25b2c1ecb9f

CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon-Trybot

http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon/builds/2120/steps/build%20most/logs/stdio

Review URL: https://codereview.chromium.org/936633002
2015-02-23 10:04:34 -08:00
mtklein
088302756b Revert of Sketch SkPMFloat (patchset #15 id:270001 of https://codereview.chromium.org/936633002/)
Reason for revert:
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon/builds/2120/steps/build%20most/logs/stdio

Original issue's description:
> Sketch SkPMFloat
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/50d2b3114b3e59dc84811881591bf25b2c1ecb9f

TBR=reed@google.com,msarrett@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/952453004
2015-02-23 09:44:34 -08:00
mtklein
50d2b3114b Sketch SkPMFloat
BUG=skia:

Review URL: https://codereview.chromium.org/936633002
2015-02-23 09:39:27 -08:00
bsalomon
8718aafec2 Rename GrContentKey to GrUniqueKey
Review URL: https://codereview.chromium.org/940463006
2015-02-19 07:24:21 -08:00
bsalomon
3582d3ee9f Split out methods in GrGpuResource::CacheAccess that can be called outside of the cache.
Review URL: https://codereview.chromium.org/923143002
2015-02-13 14:20:05 -08:00
msarett
95f192d199 Adding new benchmark to test image decoding performance.
BUG=skia:

Review URL: https://codereview.chromium.org/918673002
2015-02-13 09:05:42 -08:00
bsalomon
0ea80f43a1 Rename GrResourceCache2->GrResourceCache
TBR=robertphillips@google.com

Review URL: https://codereview.chromium.org/921453002
2015-02-11 10:49:59 -08:00
joshualitt
02b05015b5 Small change to use a GrGeometryProcessor for all BitmapText draw calls
BUG=skia:

Review URL: https://codereview.chromium.org/914723002
2015-02-11 06:56:30 -08:00
mtklein
bfd5bff75c Simplify SkBBH::insert API
No one's exploiting the ability to take ownership of the array anymore.

BUG=skia:

Review URL: https://codereview.chromium.org/913833002
2015-02-10 13:44:27 -08:00
mtklein
57f27bdcbd Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of https://codereview.chromium.org/743613005/)
Reason for revert:
Well, it still crashes.

Original issue's description:
> nanobench: lazily decode bitmaps in .skps.
>
> This cuts down on tool overhead when running something like recording only,
>     $ out/Release/nanobench --match skp --config nonrendering
> which doesn't usually ever need to decode the images.
>
> The actual measurements for recording don't change, as the decode is not in the timed section.  It just skips irrelevant code, removing it from the profile and making the tool run faster.
>
> This does, however, make a significant difference for playback speed.  Most skps draw faster with this patch, some slower.  I don't really have a good intuition for what's going on here.  There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded.  Ideas?  Is this perhaps because we're now blitting from smaller, partially decoded source images?
>
> ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log
>                    tabl_slashdot.skp_1	2.76ms -> 4.33ms	1.57x
>                tabl_slashdot.skp_1_mpd	2.79ms -> 4.07ms	1.46x
>                     tabl_sahadan.skp_1	3.41ms -> 4.87ms	1.43x
>                  tabl_googleblog.skp_1	1.52ms -> 2.05ms	1.35x
>                tabl_techmeme.skp_1_mpd	1.14ms -> 1.51ms	1.32x
>                tabl_transformice.skp_1	2.61ms -> 3.43ms	1.31x
>                 tabl_sahadan.skp_1_mpd	3.54ms -> 4.48ms	1.26x
>                    tabl_techmeme.skp_1	1.01ms -> 1.27ms	1.26x
>                 tabl_nytimes.skp_1_mpd	   1ms -> 1.23ms	1.23x
>            tabl_worldjournal.skp_1_mpd	1.98ms -> 2.43ms	1.23x
>                  tabl_pravda.skp_1_mpd	2.05ms -> 2.51ms	1.22x
>            tabl_transformice.skp_1_mpd	2.75ms -> 3.19ms	1.16x
>                     tabl_nytimes.skp_1	 874us -> 1.01ms	1.15x
>                      tabl_pravda.skp_1	1.83ms -> 1.99ms	1.09x
>                tabl_worldjournal.skp_1	1.76ms -> 1.91ms	1.09x
>                 desk_wowwiki.skp_1_mpd	 3.7ms ->  3.9ms	1.05x
>                        tabl_digg.skp_1	3.99ms -> 4.16ms	1.04x
>                   tabl_ukwsj.skp_1_mpd	   3ms -> 3.12ms	1.04x
>                     desk_booking.skp_1	3.74ms -> 3.81ms	1.02x
>     desk_googlespreadsheetdashed.skp_1	10.6ms -> 10.6ms	1x
>                       tabl_ukwsj.skp_1	2.88ms -> 2.89ms	1x
> desk_googlespreadsheetdashed.skp_1_mpd	11.8ms -> 11.8ms	1x
>      desk_jsfiddlehumperclip.skp_1_mpd	 891us ->  888us	1x
>           desk_googlespreadsheet.skp_1	4.65ms -> 4.62ms	0.99x
>                   tabl_gspro.skp_1_mpd	1.97ms -> 1.94ms	0.99x
>                 desk_booking.skp_1_mpd	 4.1ms ->    4ms	0.98x
>                      desk_carsvg.skp_1	18.2ms -> 17.7ms	0.97x
>             desk_gmailthread.skp_1_mpd	2.81ms -> 2.73ms	0.97x
>                desk_tigersvg.skp_1_mpd	19.5ms -> 18.9ms	0.97x
>                      desk_mapsvg.skp_1	88.4ms -> 85.6ms	0.97x
>                    tabl_cnet.skp_1_mpd	1.43ms -> 1.38ms	0.97x
>              desk_jsfiddlebigcar.skp_1	1.26ms -> 1.22ms	0.96x
>                         desk_gws.skp_1	1.87ms ->  1.8ms	0.96x
>                    desk_linkedin.skp_1	2.07ms -> 1.98ms	0.96x
>              tabl_deviantart.skp_1_mpd	 118ms ->  113ms	0.96x
>                        tabl_cnet.skp_1	 1.2ms -> 1.14ms	0.95x
>           tabl_androidpolice.skp_1_mpd	5.95ms -> 5.63ms	0.95x
>                      desk_sfgate.skp_1	1.75ms -> 1.64ms	0.94x
>                     desk_twitter.skp_1	  74ms -> 69.6ms	0.94x
>                 desk_youtube.skp_1_mpd	3.17ms -> 2.96ms	0.93x
>                 desk_gmailthread.skp_1	2.73ms -> 2.54ms	0.93x
>             desk_silkfinance.skp_1_mpd	1.71ms -> 1.59ms	0.93x
>          desk_jsfiddlebigcar.skp_1_mpd	1.45ms -> 1.35ms	0.93x
>             desk_pokemonwiki.skp_1_mpd	2.72ms -> 2.51ms	0.92x
>                     desk_gws.skp_1_mpd	2.14ms -> 1.98ms	0.92x
>                  desk_googlehome.skp_1	 563us ->  517us	0.92x
>                        desk_espn.skp_1	4.24ms -> 3.89ms	0.92x
>           tabl_culturalsolutions.skp_1	12.7ms -> 11.6ms	0.91x
>                  desk_sfgate.skp_1_mpd	1.91ms -> 1.74ms	0.91x
>                        tabl_hsfi.skp_1	1.06ms ->  966us	0.91x
>                desk_samoasvg.skp_1_mpd	10.5ms -> 9.47ms	0.91x
>                desk_facebook.skp_1_mpd	 3.8ms -> 3.43ms	0.9x
>                     desk_youtube.skp_1	3.52ms -> 3.14ms	0.89x
>                    desk_ebay.skp_1_mpd	2.95ms -> 2.62ms	0.89x
>                    desk_samoasvg.skp_1	10.9ms -> 9.66ms	0.89x
>       desk_googlespreadsheet.skp_1_mpd	5.59ms -> 4.94ms	0.88x
>                  desk_mapsvg.skp_1_mpd	 100ms -> 87.9ms	0.88x
>                    desk_espn.skp_1_mpd	 4.7ms -> 4.12ms	0.88x
>               desk_wordpress.skp_1_mpd	1.92ms -> 1.68ms	0.87x
>                  tabl_deviantart.skp_1	 140ms ->  122ms	0.87x
>            tabl_cuteoverload.skp_1_mpd	4.41ms -> 3.83ms	0.87x
>                    desk_tigersvg.skp_1	19.6ms ->   17ms	0.87x
>              tabl_googlecalendar.skp_1	4.01ms -> 3.44ms	0.86x
>                     desk_blogger.skp_1	2.49ms -> 2.14ms	0.86x
>              desk_chalkboard.skp_1_mpd	52.7ms ->   45ms	0.85x
>                     desk_weather.skp_1	2.88ms -> 2.46ms	0.85x
>                  desk_chalkboard.skp_1	  51ms -> 43.4ms	0.85x
>                desk_yahooanswers.skp_1	2.74ms -> 2.32ms	0.85x
>              desk_forecastio.skp_1_mpd	1.26ms -> 1.07ms	0.85x
>               tabl_androidpolice.skp_1	5.18ms -> 4.34ms	0.84x
>            desk_yahooanswers.skp_1_mpd	3.44ms -> 2.85ms	0.83x
>                     tabl_cnn.skp_1_mpd	2.59ms -> 2.15ms	0.83x
>                   desk_pinterest.skp_1	2.69ms -> 2.22ms	0.83x
>                    tabl_hsfi.skp_1_mpd	 1.6ms -> 1.32ms	0.82x
>       tabl_culturalsolutions.skp_1_mpd	13.8ms -> 11.3ms	0.82x
>                 desk_twitter.skp_1_mpd	76.6ms ->   63ms	0.82x
>                        desk_ebay.skp_1	3.11ms -> 2.51ms	0.81x
>                     tabl_mlb.skp_1_mpd	3.17ms -> 2.53ms	0.8x
>                     tabl_mozilla.skp_1	2.42ms -> 1.91ms	0.79x
>                 desk_pokemonwiki.skp_1	2.84ms -> 2.22ms	0.78x
>                  desk_carsvg.skp_1_mpd	23.3ms -> 17.8ms	0.77x
>                     desk_wowwiki.skp_1	4.21ms -> 3.21ms	0.76x
>                      desk_amazon.skp_1	 963us ->  728us	0.76x
>               desk_css3gradients.skp_1	2.58ms -> 1.92ms	0.74x
>                tabl_cuteoverload.skp_1	4.55ms -> 3.38ms	0.74x
>                         tabl_cnn.skp_1	3.13ms -> 2.29ms	0.73x
>              tabl_googleblog.skp_1_mpd	2.32ms ->  1.7ms	0.73x
>                  desk_mobilenews.skp_1	3.65ms -> 2.61ms	0.71x
>                  desk_googleplus.skp_1	3.76ms -> 2.66ms	0.71x
>                 tabl_mozilla.skp_1_mpd	2.88ms -> 2.03ms	0.71x
>               desk_pinterest.skp_1_mpd	3.17ms -> 2.21ms	0.7x
>           desk_css3gradients.skp_1_mpd	2.98ms -> 2.07ms	0.69x
>                 desk_silkfinance.skp_1	2.06ms -> 1.42ms	0.69x
>                    desk_facebook.skp_1	 4.5ms -> 3.07ms	0.68x
>              desk_mobilenews.skp_1_mpd	4.05ms -> 2.73ms	0.68x
>                   desk_baidu.skp_1_mpd	2.73ms -> 1.81ms	0.66x
>                 desk_weather.skp_1_mpd	3.93ms ->  2.5ms	0.64x
>                   desk_wordpress.skp_1	2.15ms -> 1.36ms	0.63x
>              desk_googlehome.skp_1_mpd	1.02ms ->  605us	0.59x
>                    desk_fontwipe.skp_1	 722us ->  402us	0.56x
>                desk_fontwipe.skp_1_mpd	 897us ->  486us	0.54x
>                       desk_baidu.skp_1	3.02ms ->  1.6ms	0.53x
>                  desk_forecastio.skp_1	2.01ms ->  999us	0.5x
>                  desk_amazon.skp_1_mpd	1.77ms ->  860us	0.49x
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109
>
> Committed: https://skia.googlesource.com/skia/+/1b6b626f9bc0deebe4fe2e63f422d6b122419205

TBR=reed@google.com,robertphillips@google.com,scroggo@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/902783005
2015-02-09 11:58:41 -08:00
mtklein
1b6b626f9b nanobench: lazily decode bitmaps in .skps.
This cuts down on tool overhead when running something like recording only,
    $ out/Release/nanobench --match skp --config nonrendering
which doesn't usually ever need to decode the images.

The actual measurements for recording don't change, as the decode is not in the timed section.  It just skips irrelevant code, removing it from the profile and making the tool run faster.

This does, however, make a significant difference for playback speed.  Most skps draw faster with this patch, some slower.  I don't really have a good intuition for what's going on here.  There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded.  Ideas?  Is this perhaps because we're now blitting from smaller, partially decoded source images?

~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log
                   tabl_slashdot.skp_1	2.76ms -> 4.33ms	1.57x
               tabl_slashdot.skp_1_mpd	2.79ms -> 4.07ms	1.46x
                    tabl_sahadan.skp_1	3.41ms -> 4.87ms	1.43x
                 tabl_googleblog.skp_1	1.52ms -> 2.05ms	1.35x
               tabl_techmeme.skp_1_mpd	1.14ms -> 1.51ms	1.32x
               tabl_transformice.skp_1	2.61ms -> 3.43ms	1.31x
                tabl_sahadan.skp_1_mpd	3.54ms -> 4.48ms	1.26x
                   tabl_techmeme.skp_1	1.01ms -> 1.27ms	1.26x
                tabl_nytimes.skp_1_mpd	   1ms -> 1.23ms	1.23x
           tabl_worldjournal.skp_1_mpd	1.98ms -> 2.43ms	1.23x
                 tabl_pravda.skp_1_mpd	2.05ms -> 2.51ms	1.22x
           tabl_transformice.skp_1_mpd	2.75ms -> 3.19ms	1.16x
                    tabl_nytimes.skp_1	 874us -> 1.01ms	1.15x
                     tabl_pravda.skp_1	1.83ms -> 1.99ms	1.09x
               tabl_worldjournal.skp_1	1.76ms -> 1.91ms	1.09x
                desk_wowwiki.skp_1_mpd	 3.7ms ->  3.9ms	1.05x
                       tabl_digg.skp_1	3.99ms -> 4.16ms	1.04x
                  tabl_ukwsj.skp_1_mpd	   3ms -> 3.12ms	1.04x
                    desk_booking.skp_1	3.74ms -> 3.81ms	1.02x
    desk_googlespreadsheetdashed.skp_1	10.6ms -> 10.6ms	1x
                      tabl_ukwsj.skp_1	2.88ms -> 2.89ms	1x
desk_googlespreadsheetdashed.skp_1_mpd	11.8ms -> 11.8ms	1x
     desk_jsfiddlehumperclip.skp_1_mpd	 891us ->  888us	1x
          desk_googlespreadsheet.skp_1	4.65ms -> 4.62ms	0.99x
                  tabl_gspro.skp_1_mpd	1.97ms -> 1.94ms	0.99x
                desk_booking.skp_1_mpd	 4.1ms ->    4ms	0.98x
                     desk_carsvg.skp_1	18.2ms -> 17.7ms	0.97x
            desk_gmailthread.skp_1_mpd	2.81ms -> 2.73ms	0.97x
               desk_tigersvg.skp_1_mpd	19.5ms -> 18.9ms	0.97x
                     desk_mapsvg.skp_1	88.4ms -> 85.6ms	0.97x
                   tabl_cnet.skp_1_mpd	1.43ms -> 1.38ms	0.97x
             desk_jsfiddlebigcar.skp_1	1.26ms -> 1.22ms	0.96x
                        desk_gws.skp_1	1.87ms ->  1.8ms	0.96x
                   desk_linkedin.skp_1	2.07ms -> 1.98ms	0.96x
             tabl_deviantart.skp_1_mpd	 118ms ->  113ms	0.96x
                       tabl_cnet.skp_1	 1.2ms -> 1.14ms	0.95x
          tabl_androidpolice.skp_1_mpd	5.95ms -> 5.63ms	0.95x
                     desk_sfgate.skp_1	1.75ms -> 1.64ms	0.94x
                    desk_twitter.skp_1	  74ms -> 69.6ms	0.94x
                desk_youtube.skp_1_mpd	3.17ms -> 2.96ms	0.93x
                desk_gmailthread.skp_1	2.73ms -> 2.54ms	0.93x
            desk_silkfinance.skp_1_mpd	1.71ms -> 1.59ms	0.93x
         desk_jsfiddlebigcar.skp_1_mpd	1.45ms -> 1.35ms	0.93x
            desk_pokemonwiki.skp_1_mpd	2.72ms -> 2.51ms	0.92x
                    desk_gws.skp_1_mpd	2.14ms -> 1.98ms	0.92x
                 desk_googlehome.skp_1	 563us ->  517us	0.92x
                       desk_espn.skp_1	4.24ms -> 3.89ms	0.92x
          tabl_culturalsolutions.skp_1	12.7ms -> 11.6ms	0.91x
                 desk_sfgate.skp_1_mpd	1.91ms -> 1.74ms	0.91x
                       tabl_hsfi.skp_1	1.06ms ->  966us	0.91x
               desk_samoasvg.skp_1_mpd	10.5ms -> 9.47ms	0.91x
               desk_facebook.skp_1_mpd	 3.8ms -> 3.43ms	0.9x
                    desk_youtube.skp_1	3.52ms -> 3.14ms	0.89x
                   desk_ebay.skp_1_mpd	2.95ms -> 2.62ms	0.89x
                   desk_samoasvg.skp_1	10.9ms -> 9.66ms	0.89x
      desk_googlespreadsheet.skp_1_mpd	5.59ms -> 4.94ms	0.88x
                 desk_mapsvg.skp_1_mpd	 100ms -> 87.9ms	0.88x
                   desk_espn.skp_1_mpd	 4.7ms -> 4.12ms	0.88x
              desk_wordpress.skp_1_mpd	1.92ms -> 1.68ms	0.87x
                 tabl_deviantart.skp_1	 140ms ->  122ms	0.87x
           tabl_cuteoverload.skp_1_mpd	4.41ms -> 3.83ms	0.87x
                   desk_tigersvg.skp_1	19.6ms ->   17ms	0.87x
             tabl_googlecalendar.skp_1	4.01ms -> 3.44ms	0.86x
                    desk_blogger.skp_1	2.49ms -> 2.14ms	0.86x
             desk_chalkboard.skp_1_mpd	52.7ms ->   45ms	0.85x
                    desk_weather.skp_1	2.88ms -> 2.46ms	0.85x
                 desk_chalkboard.skp_1	  51ms -> 43.4ms	0.85x
               desk_yahooanswers.skp_1	2.74ms -> 2.32ms	0.85x
             desk_forecastio.skp_1_mpd	1.26ms -> 1.07ms	0.85x
              tabl_androidpolice.skp_1	5.18ms -> 4.34ms	0.84x
           desk_yahooanswers.skp_1_mpd	3.44ms -> 2.85ms	0.83x
                    tabl_cnn.skp_1_mpd	2.59ms -> 2.15ms	0.83x
                  desk_pinterest.skp_1	2.69ms -> 2.22ms	0.83x
                   tabl_hsfi.skp_1_mpd	 1.6ms -> 1.32ms	0.82x
      tabl_culturalsolutions.skp_1_mpd	13.8ms -> 11.3ms	0.82x
                desk_twitter.skp_1_mpd	76.6ms ->   63ms	0.82x
                       desk_ebay.skp_1	3.11ms -> 2.51ms	0.81x
                    tabl_mlb.skp_1_mpd	3.17ms -> 2.53ms	0.8x
                    tabl_mozilla.skp_1	2.42ms -> 1.91ms	0.79x
                desk_pokemonwiki.skp_1	2.84ms -> 2.22ms	0.78x
                 desk_carsvg.skp_1_mpd	23.3ms -> 17.8ms	0.77x
                    desk_wowwiki.skp_1	4.21ms -> 3.21ms	0.76x
                     desk_amazon.skp_1	 963us ->  728us	0.76x
              desk_css3gradients.skp_1	2.58ms -> 1.92ms	0.74x
               tabl_cuteoverload.skp_1	4.55ms -> 3.38ms	0.74x
                        tabl_cnn.skp_1	3.13ms -> 2.29ms	0.73x
             tabl_googleblog.skp_1_mpd	2.32ms ->  1.7ms	0.73x
                 desk_mobilenews.skp_1	3.65ms -> 2.61ms	0.71x
                 desk_googleplus.skp_1	3.76ms -> 2.66ms	0.71x
                tabl_mozilla.skp_1_mpd	2.88ms -> 2.03ms	0.71x
              desk_pinterest.skp_1_mpd	3.17ms -> 2.21ms	0.7x
          desk_css3gradients.skp_1_mpd	2.98ms -> 2.07ms	0.69x
                desk_silkfinance.skp_1	2.06ms -> 1.42ms	0.69x
                   desk_facebook.skp_1	 4.5ms -> 3.07ms	0.68x
             desk_mobilenews.skp_1_mpd	4.05ms -> 2.73ms	0.68x
                  desk_baidu.skp_1_mpd	2.73ms -> 1.81ms	0.66x
                desk_weather.skp_1_mpd	3.93ms ->  2.5ms	0.64x
                  desk_wordpress.skp_1	2.15ms -> 1.36ms	0.63x
             desk_googlehome.skp_1_mpd	1.02ms ->  605us	0.59x
                   desk_fontwipe.skp_1	 722us ->  402us	0.56x
               desk_fontwipe.skp_1_mpd	 897us ->  486us	0.54x
                      desk_baidu.skp_1	3.02ms ->  1.6ms	0.53x
                 desk_forecastio.skp_1	2.01ms ->  999us	0.5x
                 desk_amazon.skp_1_mpd	1.77ms ->  860us	0.49x

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109

Review URL: https://codereview.chromium.org/743613005
2015-02-09 11:44:23 -08:00
reed
70a8ca8351 add rounded-join option to bigpath bench
BUG=skia:
TBR=
NOTRY=True
... win bot offline

Review URL: https://codereview.chromium.org/909893002
2015-02-09 08:05:52 -08:00
reed
37a4736971 add bench for very big paths
BUG= 455429
TBR=

Review URL: https://codereview.chromium.org/909563002
2015-02-06 13:04:16 -08:00
bsalomon
b12ea41286 Add texture create/upload stats and make nanobench have explicit gpu stats flag
Review URL: https://codereview.chromium.org/891973002
2015-02-02 21:19:50 -08:00
reed
96638d1db4 add bench for building mipmaps
BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/873293003
2015-01-26 12:28:54 -08:00
cwallez
c12b74dc41 Collapse consecutive SkTableColorFilters
BUG=skia:1366

For the added bench, the collapsing makes the bench take:
- 70% of the time for CPU rendering of 3 consecutive matrix filters
- almost no change in the GPU rendering of the matrix filters
- 50% of the time for CPU and GPU rendering of 3 consecutive table filters

Review URL: https://codereview.chromium.org/776673002
2015-01-26 07:45:53 -08:00
tfarina
0004e7db42 Update references to skiaperf.com.
The new server is being run in perf.skia.org.

BUG=None
R=jcgregorio@google.com

Review URL: https://codereview.chromium.org/866943003
2015-01-26 06:47:55 -08:00
mtklein
1c4029296f remove unused GM flags
Depends on https://codereview.chromium.org/873753002/

Thumbs up to CLion for refactoring this for me.

BUG=skia:

Review URL: https://codereview.chromium.org/867963004
2015-01-23 11:07:08 -08:00