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
mtklein
cf5d9c993d
Spin off GM::runAsBench() from flags.
...
This will let us kill flags.
BUG=skia:
Review URL: https://codereview.chromium.org/873753002
2015-01-23 10:31:45 -08:00
bsalomon
24db3b1c35
Add specialized content key class for resources.
...
Review URL: https://codereview.chromium.org/858123002
2015-01-23 04:24:05 -08:00
mtklein
55e88b226c
More natural way to serialize GPU tasks and tests.
...
This basically takes out the Windows-only hacks and promotes them to
cross-platform behavior driven by --gpu_threading.
- When --gpu_threading is false (the default), this puts GPU tasks and tests
together in the same GPU enclave. They all run serially.
- When --gpu_threading is true, both the tests and the tasks run totally
independently, just like the thread-safe CPU-bound work.
BUG=skia:3255
Review URL: https://codereview.chromium.org/847273005
2015-01-21 15:50:13 -08:00
scroggo
a1193e4b0e
Make SkStream *not* ref counted.
...
SkStream is a stateful object, so it does not make sense for it to have
multiple owners. Make SkStream inherit directly from SkNoncopyable.
Update methods which previously called SkStream::ref() (e.g.
SkImageDecoder::buildTileIndex() and SkFrontBufferedStream::Create(),
which required the existing owners to call SkStream::unref()) to take
ownership of their SkStream parameters and delete when done (including
on failure).
Switch all SkAutoTUnref<SkStream>s to SkAutoTDelete<SkStream>s. In some
cases this means heap allocating streams that were previously stack
allocated.
Respect ownership rules of SkTypeface::CreateFromStream() and
SkImageDecoder::buildTileIndex().
Update the comments for exceptional methods which do not affect the
ownership of their SkStream parameters (e.g.
SkPicture::CreateFromStream() and SkTypeface::Deserialize()) to be
explicit about ownership.
Remove test_stream_life, which tested that buildTileIndex() behaved
correctly when SkStream was a ref counted object. The test does not
make sense now that it is not.
In SkPDFStream, remove the SkMemoryStream member. Instead of using it,
create a new SkMemoryStream to pass to fDataStream (which is now an
SkAutoTDelete).
Make other pdf rasterizers behave like SkPDFDocumentToBitmap.
SkPDFDocumentToBitmap delete the SkStream, so do the same in the
following pdf rasterizers:
SkPopplerRasterizePDF
SkNativeRasterizePDF
SkNoRasterizePDF
Requires a change to Android, which currently treats SkStreams as ref
counted objects.
Review URL: https://codereview.chromium.org/849103004
2015-01-21 12:09:53 -08:00
bsalomon
afe3005be3
Require budget decision when creating a RenderTarget SkSurface.
...
Restructure SkGpuDevice creation:
*SkSurfaceProps are optional.
*Use SkSurfaceProps to communicate DF text rather than a flag.
*Tell SkGpuDevice::Create whether RT comes from cache or not.
Review URL: https://codereview.chromium.org/848903004
2015-01-16 07:32:33 -08:00
mtklein
748ca3bf2d
Sketch DM refactor.
...
BUG=skia:3255
I think this supports everything DM used to, but has completely refactored how
it works to fit the design in the bug.
Configs like "tiles-gpu" are automatically wired up.
I wouldn't suggest looking at this as a diff. There's just a bunch of deleted
files, a few new files, and one new file that shares a name with a deleted file
(DM.cpp).
NOTREECHECKS=true
Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88
Review URL: https://codereview.chromium.org/788243008
2015-01-15 10:56:12 -08:00
mtklein
114c3cd054
Revert of Sketch DM refactor. (patchset #45 id:850001 of https://codereview.chromium.org/788243008/ )
...
Reason for revert:
plenty of data
Original issue's description:
> Sketch DM refactor.
>
> BUG=skia:3255
>
>
> I think this supports everything DM used to, but has completely refactored how
> it works to fit the design in the bug.
>
> Configs like "tiles-gpu" are automatically wired up.
>
> I wouldn't suggest looking at this as a diff. There's just a bunch of deleted
> files, a few new files, and one new file that shares a name with a deleted file
> (DM.cpp).
>
> NOTREECHECKS=true
>
> Committed: https://skia.googlesource.com/skia/+/709d2c3e5062c5b57f91273bfc11a751f5b2bb88
TBR=bsalomon@google.com ,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:3255
Review URL: https://codereview.chromium.org/853883004
2015-01-15 10:15:02 -08:00
mtklein
709d2c3e50
Sketch DM refactor.
...
BUG=skia:3255
I think this supports everything DM used to, but has completely refactored how
it works to fit the design in the bug.
Configs like "tiles-gpu" are automatically wired up.
I wouldn't suggest looking at this as a diff. There's just a bunch of deleted
files, a few new files, and one new file that shares a name with a deleted file
(DM.cpp).
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/788243008
2015-01-15 08:30:25 -08:00
bsalomon
5236cf480d
Make uncached textures uncached from the get go.
...
This avoids the problem of a newly created uncached texture causing a purge of cached resources.
BUG=chromium:445885
Review URL: https://codereview.chromium.org/846303002
2015-01-14 10:42:08 -08:00
mtklein
72c9faab45
Fix up all the easy virtual ... SK_OVERRIDE cases.
...
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
2015-01-09 10:06:40 -08:00
mtklein
d0256a2fbc
PictureNestingBench: stay in ints.
...
BUG=skia:
Review URL: https://codereview.chromium.org/784173004
2015-01-09 08:33:36 -08:00
mtklein
703dd2ed18
Remove SkTileGrid (except for TileGridInfo).
...
TBR=reed@google.com
BUG=skia:3085
Review URL: https://codereview.chromium.org/845623002
2015-01-09 06:41:48 -08:00
reed
5965c8ae4e
add ImageGenerator::NewFromData to porting layer
...
BUG=skia:3275
Review URL: https://codereview.chromium.org/834633006
2015-01-07 18:04:45 -08:00
tfarina
aa458fb20a
Cleanup: More override fixes - another round.
...
BUG=skia:3075
TEST=ninja -C out/Debug
TBR=reed@google.com
Review URL: https://codereview.chromium.org/831113002
2015-01-05 17:18:51 -08:00
bsalomon
7775c85611
Add a simpler key type for scratch resource keys.
...
BUG=skia:2889
Review URL: https://codereview.chromium.org/815833004
2014-12-30 12:50:52 -08:00
tfarina
1348dfd5df
Cleanup: Remove a bunch of SkFontHost.h includes (unused).
...
Nobody that is including SkFontHost is using SkFontHost API, so lets
remove this includes, since the API per se is deprecated.
BUG=None
R=reed@google.com
Review URL: https://codereview.chromium.org/803733006
2014-12-18 05:48:53 -08:00
bsalomon
0aa5cea869
fix last warnings on w64 and turn on w.a.e.
...
Review URL: https://codereview.chromium.org/801413002
2014-12-15 09:13:35 -08:00
Florin Malita
c54d8db4d1
Remove SkCanvas::drawBitmapMatrix()
...
R=mtklein@google.com , reed@google.com , robertphillips@google.com
Review URL: https://codereview.chromium.org/789033002
2014-12-10 12:02:16 -05:00
qiankun.miao
e18a530afd
Add bench to measure blur rects performance
...
BUG=skia:
Review URL: https://codereview.chromium.org/787913002
2014-12-09 17:47:05 -08:00
robertphillips
e451c4df73
Update nanobench so the non-MPD path doesn't permit layer hoisting
...
Review URL: https://codereview.chromium.org/787923002
2014-12-09 10:28:00 -08:00
robertphillips
a3e52724ac
Switch non-MPD nanobench path to use a separate canvas per tile
...
It is desirable that, when layer hoisting is disabled, the MPD and non-MPD timings be
roughly the same. Unfortunately, using a separate canvas for each tile (a requirement
for MPD) introduces its own discrepancy into the timing. Using a separate canvas for
each tile doesn't seem to make a difference for 8888 (see the non-MPD 8888 column below)
but slows down GPU rendering (see the non-MPD GPU column below). Since this is how
Chromium renders I propose switching to this regimen (even though it is "slowing down"
GPU rendering).
nanobench mean times (ms) with layer hoisting disabled (for desk_amazon.skp)
8888
MPD non-MPD
1 canvas (old-style) 0.628 1.71
separate (new-style) 0.795 1.63
GPU
MPD non-MPD
1 canvas (old-style) 2.34 1.69
separate (new-style) 2.32 2.66
Review URL: https://codereview.chromium.org/779643002
2014-12-09 10:27:54 -08:00
mtklein
5a8fc33320
Don't upload metrics we don't want to track.
...
BUG=skia:
Review URL: https://codereview.chromium.org/758853004
2014-12-05 07:25:16 -08:00
mtklein
e109145bf3
nanobench: upload peak memory usage as its own trace.
...
We'll end up with a result like this:
"memory_usage" : {
"meta" : {
"max_rss_mb" : 57
}
}
BUG=skia:
Review URL: https://codereview.chromium.org/780013002
2014-12-04 10:47:02 -08:00
mtklein
051e56df8f
Upload picture byte size and op count metrics for SKP recording.
...
Look okay?
{
"results" : {
"desk_amazon.skp_1264_3999" : {
"nonrendering" : {
"bytes" : 75656,
"max_ms" : 1.150187,
"mean_ms" : 1.150187,
"median_ms" : 1.150187,
"min_ms" : 1.150187,
"ops" : 659,
"options" : {
"bench_type" : "recording",
"clip" : "0 0 1000 1000",
"name" : "desk_amazon.skp",
"scale" : "1",
"source_type" : "skp"
}
}
},
...
BUG=skia:
Review URL: https://codereview.chromium.org/773323002
2014-12-04 08:46:51 -08:00
robertphillips
63242d7d24
Fix SKPBench tiling so MPD and non-MPD match
...
Two issues with the SKPBench tile computation were causing the MPD path to do more work:
The clip from the parent canvas wasn't being used to trim content off the edges of the MPD tiles
The non-MPD path was not taking the scale into account in its tile placement (resulting in it having fewer, larger active tiles when scaling).
Review URL: https://codereview.chromium.org/776273002
2014-12-04 08:31:03 -08:00
mtklein
4f10844149
Turn on MPD threading in nanobench.
...
Seems okay after this small patch to skip lockPixels() / unlockPixels().
BUG=skia:3149
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu13.10-GCE-NoGPU-x86_64-Release-TSAN-Trybot
Review URL: https://codereview.chromium.org/773203003
2014-12-03 13:07:39 -08:00
mtklein
535776eb28
Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of https://codereview.chromium.org/743613005/ )
...
Reason for revert:
Some bots crashing.
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
TBR=reed@google.com ,robertphillips@google.com,scroggo@google.com,mtklein@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/759753004
2014-11-25 14:57:26 -08:00
mtklein
7e225bdb1f
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:
Review URL: https://codereview.chromium.org/743613005
2014-11-25 14:34:03 -08:00
bsalomon
10e23caea3
Use scratch keys for stencil buffers.
...
BUG=skia:2889
Committed: https://skia.googlesource.com/skia/+/91175f19664a62851da4ca4e0984a7c7c45b258f
Review URL: https://codereview.chromium.org/747043004
2014-11-25 05:52:06 -08:00
