aboutsummaryrefslogtreecommitdiffhomepage
path: root/bench
Commit message (Collapse)AuthorAge
* Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of ↵Gravatar mtklein2014-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* nanobench: lazily decode bitmaps in .skps.Gravatar mtklein2014-11-25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use scratch keys for stencil buffers.Gravatar bsalomon2014-11-25
| | | | | | | | BUG=skia:2889 Committed: https://skia.googlesource.com/skia/+/91175f19664a62851da4ca4e0984a7c7c45b258f Review URL: https://codereview.chromium.org/747043004
* Revert "Use scratch keys for stencil buffers."Gravatar bsalomon2014-11-24
| | | | | | | | | | | | | | | | This reverts commit 91175f19664a62851da4ca4e0984a7c7c45b258f. Revert "Cleanup res cache bench and split out into a unit test." This reverts commit 4e4303f002c5958c6c958e7ba8e49b24c25f0b22. Revert "rebaselines" This reverts commit 65ba7b57759bfca60b24bc34dc46fc8caaf146f0. TBR=tomhudson@google.com Review URL: https://codereview.chromium.org/752233002
* add some debugging to SkNVRefCntGravatar reed2014-11-24
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/745383003
* Cleanup res cache bench and split out into a unit test.Gravatar bsalomon2014-11-24
| | | | | | BUG=skia:2889 Review URL: https://codereview.chromium.org/754833002
* Use scratch keys for stencil buffers.Gravatar bsalomon2014-11-24
| | | | | | BUG=skia:2889 Review URL: https://codereview.chromium.org/747043004
* Fix memory leak in nanobenchGravatar robertphillips2014-11-21
| | | | | | This is cleanup for (Add MultiPictureDraw to nanobench - https://codereview.chromium.org/731973005/) Review URL: https://codereview.chromium.org/730343003
* Add MultiPictureDraw to nanobenchGravatar robertphillips2014-11-21
| | | | | | | | | | I would like some guard against performance regressions on our side before turning layer hoisting on in Chromium. TBR=bsalomon@google.com Committed: https://skia.googlesource.com/skia/+/0ddad31012dabfc1267effc8071d37f7d606efbe Review URL: https://codereview.chromium.org/731973005
* Revert of Add MultiPictureDraw to nanobench (patchset #7 id:120001 of ↵Gravatar robertphillips2014-11-21
| | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/731973005/) Reason for revert: Needs more work Original issue's description: > Add MultiPictureDraw to nanobench > > I would like some guard against performance regressions on our side before turning layer hoisting on in Chromium. > > TBR=bsalomon@google.com > > Committed: https://skia.googlesource.com/skia/+/0ddad31012dabfc1267effc8071d37f7d606efbe TBR=mtklein@google.com,bsalomon@google.com NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/750583002
* Add MultiPictureDraw to nanobenchGravatar robertphillips2014-11-21
| | | | | | | | I would like some guard against performance regressions on our side before turning layer hoisting on in Chromium. TBR=bsalomon@google.com Review URL: https://codereview.chromium.org/731973005
* Add computation of saveLayer information to RecordingBenchGravatar robertphillips2014-11-18
| | | | | | In (Add flag to beginRecording to request saveLayer information - https://codereview.chromium.org/721883002/) I claimed the extra recording cost would be negligible. This CL attempts to put some numbers behind that. Review URL: https://codereview.chromium.org/741523002
* Prune SkRTreeGravatar mtklein2014-11-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Propagate a bunch of constant parameters through. - Delete code that's not used when bulk loading. - Allocate all Nodes together. - Stay in SkRect. Doing a single malloc for the nodes can't not have improved memory usage. Looks like this might improve record performance ~5%, probably mostly from staying in SkRects. This finally dethrones building the BBH as the hot spot. (Now it's mapping user bounds back to device bounds and adjusting for paints.) Recording time changes from my MBP: desk_rectangletransition.skp 11.5us -> 11.7us 1x desk_forecastio.skp 115us -> 114us 0.98x desk_booking.skp 550us -> 541us 0.98x tabl_mercurynews.skp 176us -> 173us 0.98x tabl_hsfi.skp 294us -> 287us 0.98x desk_wordpress.skp 351us -> 343us 0.98x tabl_worldjournal.skp 439us -> 426us 0.97x tabl_gmail.skp 20.3us -> 19.7us 0.97x desk_youtubetvvideo.skp 10.8us -> 10.4us 0.97x desk_googleplus.skp 1.1ms -> 1.07ms 0.97x tabl_slashdot.skp 106us -> 103us 0.97x desk_jsfiddlebigcar.skp 26.7us -> 25.7us 0.96x tabl_techmeme.skp 95.4us -> 91.7us 0.96x tabl_deviantart.skp 133us -> 127us 0.96x desk_pinterest.skp 40.6us -> 38.9us 0.96x desk_carsvg.skp 195us -> 187us 0.96x tabl_engadget.skp 376us -> 359us 0.96x tabl_sahadan.skp 60.5us -> 57.5us 0.95x tabl_culturalsolutions.skp 255us -> 242us 0.95x tabl_gspro.skp 58.3us -> 55.5us 0.95x desk_linkedin.skp 146us -> 138us 0.94x desk_ebay.skp 192us -> 181us 0.94x tabl_cnn.skp 467us -> 440us 0.94x desk_jsfiddlehumperclip.skp 29.9us -> 28.1us 0.94x desk_tigersvg.skp 43.2us -> 40.5us 0.94x desk_yahooanswers.skp 131us -> 123us 0.94x desk_googlespreadsheetdashed.skp 1.18ms -> 1.11ms 0.94x desk_blogger.skp 193us -> 181us 0.94x tabl_mozilla.skp 1.82ms -> 1.7ms 0.94x tabl_mlb.skp 145us -> 136us 0.93x mobi_wikipedia.skp 577us -> 539us 0.93x tabl_frantzen.skp 54.1us -> 50.4us 0.93x desk_baidu.skp 87.9us -> 81.9us 0.93x desk_techcrunch.skp 224us -> 209us 0.93x desk_sfgate.skp 206us -> 192us 0.93x tabl_ukwsj.skp 269us -> 250us 0.93x desk_facebook.skp 316us -> 293us 0.93x desk_gmailthread.skp 205us -> 190us 0.93x tabl_googlecalendar.skp 158us -> 147us 0.93x tabl_digg.skp 382us -> 354us 0.93x desk_amazon.skp 106us -> 98.5us 0.93x tabl_androidpolice.skp 693us -> 642us 0.93x tabl_nytimes.skp 206us -> 191us 0.92x desk_gws.skp 124us -> 114us 0.92x desk_youtube.skp 255us -> 235us 0.92x tabl_cuteoverload.skp 583us -> 537us 0.92x desk_oldinboxapp.skp 18us -> 16.6us 0.92x desk_mobilenews.skp 297us -> 273us 0.92x tabl_pravda.skp 168us -> 154us 0.92x tabl_vnexpress.skp 236us -> 217us 0.92x desk_css3gradients.skp 202us -> 185us 0.92x tabl_gamedeksiam.skp 508us -> 464us 0.91x desk_wowwiki.skp 1.02ms -> 929us 0.91x desk_espn.skp 209us -> 191us 0.91x desk_chalkboard.skp 315us -> 284us 0.9x desk_mapsvg.skp 607us -> 543us 0.89x desk_pokemonwiki.skp 5.18ms -> 4.62ms 0.89x desk_samoasvg.skp 335us -> 298us 0.89x desk_youtubetvbrowse.skp 10.1us -> 8.59us 0.85x BUG=skia:3085, skia:2834 Review URL: https://codereview.chromium.org/734723002
* Do not calculate many sierpinski fractals for each nanobench run unless neededGravatar kkinnunen2014-11-18
| | | | | | | | | | Removes work done by the constructors of picture_nesting benches, and moves the work to the Benchmark::onPreDraw override. This avoids PictureNesting::sierpinsky showing up in profile traces when profiling other benches. Review URL: https://codereview.chromium.org/725523002
* Make GrResourceCache2 responsible for calling release, abandon, and ~.Gravatar bsalomon2014-11-14
| | | | | | | | | | BUG=skia:2889 TBR=robertphillips@google.com NOTRY=true Review URL: https://codereview.chromium.org/729683002
* Replace GrResourceCache with GrResourceCache2.Gravatar bsalomon2014-11-14
| | | | | | | | | | BUG=skia:2889 Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6 Committed: https://skia.googlesource.com/skia/+/407aa584d183c1bf314f5defd1cf0202e8a96c89 Review URL: https://codereview.chromium.org/716143004
* Revert of Replace GrResourceCache with GrResourceCache2. (patchset #7 ↵Gravatar bsalomon2014-11-14
| | | | | | | | | | | | | | | | | | | | | | | id:120001 of https://codereview.chromium.org/716143004/) Reason for revert: broken again Original issue's description: > Replace GrResourceCache with GrResourceCache2. > > BUG=skia:2889 > > Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6 > > Committed: https://skia.googlesource.com/skia/+/407aa584d183c1bf314f5defd1cf0202e8a96c89 TBR=robertphillips@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2889 Review URL: https://codereview.chromium.org/726913002
* Replace GrResourceCache with GrResourceCache2.Gravatar bsalomon2014-11-14
| | | | | | | | BUG=skia:2889 Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6 Review URL: https://codereview.chromium.org/716143004
* Revert of Replace GrResourceCache with GrResourceCache2. (patchset #6 ↵Gravatar bsalomon2014-11-13
| | | | | | | | | | | | | | | | | | | | | id:100001 of https://codereview.chromium.org/716143004/) Reason for revert: Breaking stuff Original issue's description: > Replace GrResourceCache with GrResourceCache2. > > BUG=skia:2889 > > Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6 TBR=robertphillips@google.com NOTREECHECKS=true NOTRY=true BUG=skia:2889 Review URL: https://codereview.chromium.org/715333003
* Replace GrResourceCache with GrResourceCache2.Gravatar bsalomon2014-11-13
| | | | | | BUG=skia:2889 Review URL: https://codereview.chromium.org/716143004
* Revert of Make nanobench and dm be usable from Chromium build (patchset #5 ↵Gravatar jcgregorio2014-11-13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | id:80001 of https://codereview.chromium.org/657373002/) Reason for revert: Causing breakages on Mac build. Original issue's description: > Make nanobench and dm be usable from Chromium build > > Move the app logic for each app as follows: > > <app>.cpp -- the file which contains main(). Embedders that compile > their own apps, such as ios shell, upcoming Chromium dm etc, do not use this. > > <app>_main.cpp -- the main logic of the Skia test application. This will be > used by Skia -compiled apps as well as embedder -compiled apps. > > <app>_main.h -- the API for the main logic. This will be > used by Skia -compiled apps as well as embedder -compiled apps. > > This way (the upcoming) Chromium dm can setup its Chromium-specific setup > in custom main(), and then call dm_main(), without the need of any > SK_BUILD_FOR_XXXX defines controlling whether the tool defines main or not. > > BUG=skia:2992 > > Committed: https://skia.googlesource.com/skia/+/c092d3bdab5f723576cc0346cea3ee282a9cb444 TBR=mtklein@chromium.org,mtklein@google.com,borenet@google.com,kkinnunen@nvidia.com NOTREECHECKS=true NOTRY=true BUG=skia:2992 Review URL: https://codereview.chromium.org/724073002
* Make nanobench and dm be usable from Chromium buildGravatar kkinnunen2014-11-13
| | | | | | | | | | | | | | | | | | | | | Move the app logic for each app as follows: <app>.cpp -- the file which contains main(). Embedders that compile their own apps, such as ios shell, upcoming Chromium dm etc, do not use this. <app>_main.cpp -- the main logic of the Skia test application. This will be used by Skia -compiled apps as well as embedder -compiled apps. <app>_main.h -- the API for the main logic. This will be used by Skia -compiled apps as well as embedder -compiled apps. This way (the upcoming) Chromium dm can setup its Chromium-specific setup in custom main(), and then call dm_main(), without the need of any SK_BUILD_FOR_XXXX defines controlling whether the tool defines main or not. BUG=skia:2992 Review URL: https://codereview.chromium.org/657373002
* Make GrGpuResource::gpuMemorySize non-virtual w/ onGpuMemorySize virtual implGravatar bsalomon2014-11-12
| | | | | | BUG=skia:2889 Review URL: https://codereview.chromium.org/702413003
* Add benchmark to compare different BBH query patterns.Gravatar mtklein2014-11-11
| | | | | | | | | | | | | | | | | On my laptop: maxrss loops min median mean max stddev samples config bench 37M 1 14ms 14.2ms 14.6ms 18.2ms 9% ▁█▁▁▁▁▂▂▂▁ gpu tiled_playback_tilegrid_tiled 40M 1 17ms 17.2ms 17.2ms 17.6ms 1% ▆▃▁█▄▇▂▁▁▁ gpu tiled_playback_tilegrid_random 40M 1 14.6ms 14.9ms 15.8ms 19.1ms 11% ▂▁▁▁▁▁▁█▅█ gpu tiled_playback_rtree_tiled 43M 1 16.5ms 16.7ms 16.8ms 17.4ms 1% ▂▃▅█▃▂▁▃▃▂ gpu tiled_playback_rtree_random 43M 1 15.9ms 16.1ms 16.5ms 18.7ms 6% ▁▁█▇▁▁▁▂▁▁ gpu tiled_playback_none_tiled 44M 1 17.9ms 17.9ms 18ms 18.1ms 1% ▂▁▅▁▇▃▁▂█▇ gpu tiled_playback_none_random TileGrid and RTree perform pretty much the same, both beating no BBH. BUG=skia:3085 Review URL: https://codereview.chromium.org/699313006
* Avoid warning in nanobench related to loop count with nvprmsaa4Gravatar kkinnunen2014-11-11
| | | | | | | | | | | | | | | | | | | | | | The tests path_hairline_{small,big}_AA_conic were calling the test function with NVPR. This caused a warning in nanobench. The here removed hunk comes from commit referring to skia:2042 ("Enable NVPR by default"). This is a workaround for a bug. The bug is fixed by the commit referring to skia:2078 ("Logan bot fails NVPR assertion in bench"). The proper fix is indeed make sure that path renderer chain ends up trying software path renderer, if the path contains conics and is a hairline. The removed hunk refers also to skia:2033 ("Figure out what is happening with conic path segments in NVPR"). The above solution is correct also in case NVPR would support conics, as NVPR would not still support hairlines. BUG=skia:2078 Review URL: https://codereview.chromium.org/685213005
* Use GrResourceCache2 to service content key lookupsGravatar bsalomon2014-11-10
| | | | | | BUG=skia:2889 Review URL: https://codereview.chromium.org/707493002
* Get gpudft support working in dm, gm, nanobench and bench_picturesGravatar jvanverth2014-11-07
| | | | | | | | | | | | Adds a new config to test distance field text. Clean up some flags and #defines to read "distance field text", not "distance field fonts" to be consistent with Chromium NOTREECHECKS=true Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960b Review URL: https://codereview.chromium.org/699453005
* Revert of Get gpudft support working in dm, gm, nanobench and bench_pictures ↵Gravatar jvanverth2014-11-06
| | | | | | | | | | | | | | | | | | | | | | | | (patchset #2 id:20001 of https://codereview.chromium.org/699453005/) Reason for revert: Not compiling in ANGLE build Original issue's description: > Get gpudft support working in dm, gm, nanobench and bench_pictures > > Adds a new config to test distance field text. > Clean up some flags and #defines to read "distance field text", > not "distance field fonts" to be consistent with Chromium > > NOTREECHECKS=true > > Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960b TBR=bsalomon@google.com,mtklein@google.com,reed@google.com NOTREECHECKS=true NOTRY=true Review URL: https://codereview.chromium.org/707723005
* Get gpudft support working in dm, gm, nanobench and bench_picturesGravatar jvanverth2014-11-06
| | | | | | | | | | Adds a new config to test distance field text. Clean up some flags and #defines to read "distance field text", not "distance field fonts" to be consistent with Chromium NOTREECHECKS=true Review URL: https://codereview.chromium.org/699453005
* Detect loops overflow for gpu benches.Gravatar mtklein2014-11-06
| | | | | | | | NOTREECHECKS=true BUG=skia: Review URL: https://codereview.chromium.org/709473002
* PictureRecordBench's benchmarks are no longer relevant with SkRecord.Gravatar mtklein2014-11-04
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/698163004
* Try out SkTree in nanobench.Gravatar mtklein2014-10-29
| | | | | | | | Looks like a fairly large recording speed win with no playback cost. BUG=skia: Review URL: https://codereview.chromium.org/653023003
* rename GrTextureDesc->GrSurfaceDesc, GrTextureFlags->GrSurfaceFlagsGravatar bsalomon2014-10-28
| | | | Review URL: https://codereview.chromium.org/682223002
* Cut down SkBBH API more.Gravatar mtklein2014-10-27
| | | | | | | | | | | | | | - The expected case is now a single bulk-load insert() call instead of N; - reserve() and flushDeferredInserts() can fold into insert() now; - SkBBH subclasses may take ownership of the bounds This appears to be a performance no-op on both my Mac and N5. I guess even the simplest indirect branch predictor ("same as last time") can predict the repeated virtual calls to SkBBH::insert() perfectly. BUG=skia: Review URL: https://codereview.chromium.org/670213002
* Print GPU cache stats in nanobench/dm with veryVerboseGravatar bsalomon2014-10-24
| | | | Review URL: https://codereview.chromium.org/680553002
* Revert "Revert of create shaderproc for nofilter-opaque-dx (patchset #7 ↵Gravatar mtklein2014-10-23
| | | | | | | | | | id:120001 of https://codereview.chromium.org/664783004/)" This reverts commit 430b795cc8a1cdbddd8fdc5511a3a523348937f7 and adds suppressions. BUG=skia: Review URL: https://codereview.chromium.org/673023002
* Revert of create shaderproc for nofilter-opaque-dx (patchset #7 id:120001 of ↵Gravatar mtklein2014-10-23
| | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/664783004/) Reason for revert: Many GMs fixed. Needs rebaseline, perhaps layout test rebaselines. Original issue's description: > create shaderproc for nofilter-opaque-dx > > > speedup nofilter > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/a40a276bcee2246439dcf816273c1307f5c3c69f TBR=djsollen@google.com,reed@google.com NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/656913005
* create shaderproc for nofilter-opaque-dxGravatar reed2014-10-23
| | | | | | | | speedup nofilter BUG=skia: Review URL: https://codereview.chromium.org/664783004
* Qualify the return value of SkImageDecoder::decodeGravatar scroggo2014-10-22
| | | | | | | | | | | | | | | | | | | | | | | Add a new enum to differentiate between a complete decode and a partial decode (with the third value being failure). Return this value from SkImageDecoder::onDecode (in all subclasses, plus SkImageDecoder_empty) and ::decode. For convenience, if the enum is treated as a boolean, success and partial success are both considered true. Note that the static helper functions (DecodeFile etc) still return true and false (for one thing, this allows us to continue to use SkImageDecoder::DecodeMemory as an SkPicture::InstallPixelRefProc in SkPicture::CreateFromStream). Also correctly report failure in SkASTCImageDecoder::onDecode when SkTextureCompressor::DecompressBufferFromFormat fails. BUG=skia:3037 BUG:b/17419670 Review URL: https://codereview.chromium.org/647023006
* SkResourceCache::Key namespace support.Gravatar fmalita2014-10-22
| | | | | | | | | | | | Add a unique-per-subclass namespace tag to make Keys from different domains comparable. Also drop the SkPictureShader cache and convert to using the global resource cache instead. R=reed@google.com,mtklein@google.com,robertphillips@google.com Review URL: https://codereview.chromium.org/668223002
* Draw SKPs in 256x256 tiles in nanobench.Gravatar mtklein2014-10-21
| | | | | | | | (This CL will certainly trigger performance regression alerts. Tiled drawing is slower than non-tiled drawing.) BUG=skia: Review URL: https://codereview.chromium.org/669983002
* Revert of Start to vectorize SkTileGrid. (patchset #48 id:1670001 of ↵Gravatar mtklein2014-10-20
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/634543004/) Reason for revert: breaks chrome GPU debug bots Original issue's description: > Start to vectorize SkTileGrid. > > This adds Sk4x.h to help. > > BUG=skia:3041 > > Committed: https://skia.googlesource.com/skia/+/90c7992bfc6330f070f7704d63372a0ec8410170 > > CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu12-ShuttleA-GTX660-x86-Debug-Trybot > > Committed: https://skia.googlesource.com/skia/+/958e9628d5f9a81aeafa78572cb4afc4b19a455a TBR=reed@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia:3041 Review URL: https://codereview.chromium.org/637863005
* Start to vectorize SkTileGrid.Gravatar mtklein2014-10-20
| | | | | | | | | | | | This adds Sk4x.h to help. BUG=skia: Committed: https://skia.googlesource.com/skia/+/90c7992bfc6330f070f7704d63372a0ec8410170 CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu12-ShuttleA-GTX660-x86-Debug-Trybot Review URL: https://codereview.chromium.org/634543004
* Revert of Start to vectorize SkTileGrid. (patchset #45 id:1430002 of ↵Gravatar mtklein2014-10-16
| | | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/634543004/) Reason for revert: Many GCC bots missing __builtin_shuffle, e.g. Test-Ubuntu12-ShuttleA-GTX660-x86-Debug-Trybot. Original issue's description: > Start to vectorize SkTileGrid. > > This adds Sk4x.h to help. > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/90c7992bfc6330f070f7704d63372a0ec8410170 TBR=reed@google.com,mtklein@chromium.org NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/663663002
* Start to vectorize SkTileGrid.Gravatar mtklein2014-10-16
| | | | | | | | This adds Sk4x.h to help. BUG=skia: Review URL: https://codereview.chromium.org/634543004
* nanobench: flush after recording every Nth data point.Gravatar mtklein2014-10-14
| | | | | | | | | | Got to keep our precious data in event of a crash. With --flushEvery 10 I'm not seeing this cost any wall time. BUG=skia: Review URL: https://codereview.chromium.org/653083003
* detect --loops is < 0 and interpret that as running forever (mostly)Gravatar reed2014-10-10
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/643143002
* faster SkRect::sortGravatar reed2014-10-10
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/646863002
* cleanup and optimize rect intersect routinesGravatar reed2014-10-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/640723004
* Attempt at fixing color cube benchGravatar sugoi2014-10-09
| | | | | | | | The original bench was hitting the cache since it was using the same color filter for all loops. By creating a new color filter within the loop, at least this part of it is solved. I'm not 100% sure this is the right way, but at least the numbers are a bit more reasonable and are affected by the output resolution. BUG=skia: Review URL: https://codereview.chromium.org/648483002