AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
20,726 Commits 1 Branch 0 Tags 544 MiB
6f96cf4bde
Commit Graph

87 Commits

Author SHA1 Message Date
joshualitt
3ebd050be5 Create a thermal manager class and wire it in to nanobench behind a flag 
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1671573002

Review URL: https://codereview.chromium.org/1671573002
 2016-02-09 07:18:08 -08:00
djsollen
14d8fa0f58 Move SkAndroidSDKCanvas to tools and ensure that it is built on all Android builds 
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1536013003

Review URL: https://codereview.chromium.org/1536013003
 2015-12-18 09:34:08 -08:00
tomhudson
3c8ceb7350 Simplify linkages to Android framework internals 
We've migrated SkHwuiRenderer into the Android Framework as
android::uirenderer::TestWindowContext in response to an internal
bug; we now delete that class and change our build references here.

R=djsollen@google.com

Review URL: https://codereview.chromium.org/1407053009
 2015-10-26 07:21:32 -07:00
mtklein
b91f7562c4 Experiment with find as a road to Gyp sanity. 
BUG=skia:

Review URL: https://codereview.chromium.org/1123173005
 2015-05-16 15:47:10 -07:00
joshualitt
261c3ad7fd Change to add zoom animations to nanobench 
BUG=skia:

Review URL: https://codereview.chromium.org/1061323003
 2015-04-27 09:16:57 -07:00
scroggo
60869a42a1 Add timing SkCodec to nanobench. 
CodecBench:
Add new class for timing using SkCodec.

DecodingBench:
Include creating a decoder inside the loop. This is to have a better
comparison against SkCodec. SkCodec's factory function does not
necessarily read the same amount as SkImageDecoder's, so in order to
have a meaningful comparison, read the entire stream from the
beginning. Also for comparison, create a new SkStream from the
SkData each time.
Add a debugging check to make sure we have an SkImageDecoder.
Add include guards.

nanobench.cpp:
Decode using SkCodec.
When decoding using SkImageDecoder, exclude benches where we decoded
to a different color type than requested. SkImageDecoder may decide to
decode to a different type, in which case the name is misleading.

TODOs:
Now that we ignore color types that do not match the desired
color type, we should add Index8. This also means calling the more
complex version of getPixels so CodecBench can support kIndex8.

BUG=skia:3257

Review URL: https://codereview.chromium.org/1044363002
 2015-04-01 12:09:17 -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
scroggo
3e5622764a Add copyright headers to remaining gyp files. 
Prevents some PRESUBMIT errors.

TBR=mtklein@google.com

Review URL: https://codereview.chromium.org/1035523003
 2015-03-25 10:22:41 -07: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
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
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
jcgregorio
3b27adef0a Revert of Make nanobench and dm be usable from Chromium build (patchset #5 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
 2014-11-13 08:06:40 -08:00
kkinnunen
c092d3bdab 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

Review URL: https://codereview.chromium.org/657373002
 2014-11-13 05:00:57 -08:00
mtklein
963504bd0a Revert of nanobench: lazily decode bitmaps from SKPs (patchset #1 id:1 of https://codereview.chromium.org/572933006/) 
Reason for revert:
skia:2944

Original issue's description:
> nanobench: lazily decode bitmaps from SKPs
>
> This makes it considerably cheaper to run SKP recording benchmarks, without
> affecting their measurements and without really affecting SKP playback
> benchmarks at all.
>
> On my machine, running out/Release/nanobench --match skp --config nondrendering
> drops in run time from 6.7s to 2.5s, and the peak RAM usage drops from 129M to 50M.
>
> I'm strongly considering making this lazy decoding the default.
>
> BUG=skia:2944
>
> Committed: https://skia.googlesource.com/skia/+/d664c21a38de98d8db210c46f7a8c4187f1534da

R=robertphillips@google.com, mtklein@chromium.org
TBR=mtklein@chromium.org, robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2944

Author: mtklein@google.com

Review URL: https://codereview.chromium.org/554583004
 2014-09-17 06:58:39 -07:00
mtklein
d664c21a38 nanobench: lazily decode bitmaps from SKPs 
This makes it considerably cheaper to run SKP recording benchmarks, without
affecting their measurements and without really affecting SKP playback
benchmarks at all.

On my machine, running out/Release/nanobench --match skp --config nondrendering
drops in run time from 6.7s to 2.5s, and the peak RAM usage drops from 129M to 50M.

I'm strongly considering making this lazy decoding the default.

BUG=skia:
R=robertphillips@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/572933006
 2014-09-16 13:36:12 -07:00
mtklein
fd731ce804 Measure picture recording speed in nanobench. 
Today we measure SkPicture playback speed, but not the time it takes to record
the SkPicture.  This fixes that by reading SKPs from disk and re-recording them.

On the console, recording shows up first as the nonrendering skp benches,
followed later by the usual playback benches:

maxrss  loops   min median  mean    max stddev  samples     config  bench
51M  2   165µs   168µs   169µs   178µs   3%  ▆▄▃█▂▄▁▂▁▁  nonrendering    tabl_slashdot.skp
57M  1   9.72ms  9.77ms  9.79ms  9.97ms  1%  █▂▂▅▃▂▁▄▂▁  nonrendering    desk_pokemonwiki.skp
57M  32  2.92µs  2.96µs  3.03µs  3.46µs  6%  ▅▁▁▁▁▁▁█▂▁  nonrendering    desk_yahoosports.skp
...
147M 1   3.86ms  3.87ms  3.97ms  4.81ms  7%  █▁▁▁▁▁▁▁▁▁  8888    tabl_slashdot.skp_1
147M 1   4.54ms  4.56ms  4.55ms  4.56ms  0%  █▅▇▅█▅▂▁▅▁  565     tabl_slashdot.skp_1
147M 2   3.08ms  3.24ms  4.17ms  8.18ms  50% █▁▁█▁▁▁▁▁▁  gpu     tabl_slashdot.skp_1
147M 1   1.61ms  1.62ms  1.69ms  2.33ms  13% █▁▁▁▁▁▁▁▁▁  8888    desk_pokemonwiki.skp_1
147M 1   1.44ms  1.44ms  1.45ms  1.47ms  1%  ▅▂█▂▂▅▁▁▂▁  565     desk_pokemonwiki.skp_1
...

On skiaperf.com, they'll also be separated out from playback benches by bench_type.

BUG=skia:
R=reed@google.com, mtklein@google.com, jcgregorio@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/559153002
 2014-09-10 12:19:30 -07:00
djsollen
d92c4c5c95 fix android framework build for nanobench 
R=mtklein@google.com, tomhudson@chromium.org, tomhudson@google.com

Author: djsollen@google.com

Review URL: https://codereview.chromium.org/495003004
 2014-08-21 13:17:50 -07:00
mtklein
1915b62637 Add --properties for things like gitHash that describe the current nanobench run. 
--key describes the type of run (describes the line on the chart), --properties
describes the run itself (describes the dot on the chart).

We'll pass --properties gitHash <git hash> build_number <build number>  --key
... to nanobench from the bots.

And... delete a whole lot of dead code.

Example: nanobench --properties gitHash foo build_number 1234 --key bar baz

{
   "build_number" : "1234",
   "gitHash" : "foo",
   "key" : {
      "bar" : "baz"
   },
   "results" : {
....

Friends with https://codereview.chromium.org/491943002
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/488213002
 2014-08-20 11:45:00 -07:00
mtklein
afb4379dbc Print max RSS in GM and nanobench too. 
Everyone used MB, so update the API to just return that.

BUG=skia:
R=halcanary@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/483323002
 2014-08-19 15:55:55 -07:00
mtklein
a7e930f640 On the bots, there's no need to link GMs into SampleApp. 
We build SampleApp on the bots to make sure it's not broken, but we don't run it.  So, there's no need to link in all the GMs as samples.

This reduces the number of copies of our GMs from 4 to 3 (gm, dm, and nanobench remain).

NOTREECHECKS=true

BUG=skia:2142
R=bsalomon@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/447803002
 2014-08-06 10:08:42 -07:00
mtklein
be21e3432e Bye bye bench. 
NOTREECHECKS=true

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

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/442343004
 2014-08-06 08:39:38 -07:00
mtklein
92007583e4 SKPs-as-benches in nanobench 
This is meant to replace bench_pictures.

CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Release-iOS-Trybot

BUG=skia:
R=bsalomon@google.com, jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/425393004
 2014-08-01 07:46:53 -07:00
mtklein
e714e75c72 nanobench: support GMs-as-benches 
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/438683002
 2014-07-31 12:13:48 -07:00
caryclark
17f0b6df72 share dm and command flags 
Share command flags between dm and unit tests.
Also, allow dm's core to be included by itself and iOSShell.

Command line flags that are the same (or nearly the same) in DM
and in skia_tests have been moved to common_flags. Authors,
please check to see that the shared common flag is correct for
the tool.

For iOS, the 'tool_main' entry point has a wrapper to allow multiple
tools to be statically linked in the iOSShell.
Since SkCommandLineFlags::Parse can only be called once, these calls
are disabled in the IOS build.

Since the iOS app directory is dynamically assigned a name, use '@' to
select it. (This is the same convention chosen by the Mobile Harness
iOS file system utilities.)

Move the heart of dm.gyp into dm.gypi so that it can be included by
itself and iOSShell.gyp.

Add tools/flags/SkCommonFlags.* to define and declare common
command line flags.

Add support for dm to iOSShell.

BUG=skia:
R=scroggo@google.com, mtklein@google.com, jvanverth@google.com, bsalomon@google.com

Author: caryclark@google.com

Review URL: https://codereview.chromium.org/389653004
 2014-07-22 10:15:35 -07:00
Mike Klein
7edaeb515c nanobench on Windows: try compiler barriers around timer instead. 
BUG=skia:

Review URL: https://codereview.chromium.org/391193003
 2014-07-15 19:04:14 -04:00
Mike Klein
f7e51ea79e Disable LTCG for nanobench. 
NOTREECHECKS=true

BUG=skia:
R=mtklein@google.com

Review URL: https://codereview.chromium.org/393953006
 2014-07-15 18:39:49 -04:00
mtklein
60317d0ffb nanobench: support --outResultsFile 
BUG=skia:
R=kelvinly@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/390933002
 2014-07-14 11:30:37 -07:00
mtklein
f372321de3 Add nanobench, a fresh look at our microbenchmark harness. 
out/Release/nanobench runs 4-5x faster on my Z620 and ~2x faster on my N5 than out/Release/bench with the same configs.

(Debug isn't really comparable.  I haven't added the Debug -> single loop check.)

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

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/347443002
 2014-06-25 14:08:00 -07:00
tfarina
2010891425 Add GYP target for sk_tool_utils.* component. 
This declares a static library target in gyp/sk_tool_utils.gyp, so other
targets can depend directly on it instead of including the source file
in their source lists.

BUG=None
TEST=make all
R=mtklein@google.com

Author: tfarina@chromium.org

Review URL: https://codereview.chromium.org/348623006
 2014-06-21 10:54:17 -07:00
mtklein
9ac68ee259 Move BenchTimer to tools as Timer 
This breaks a bunch of circular dependencies between tools and gm and bench.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/4ed75287aed6371c6e4a41ffcc78c8a49c9810ed

CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot,Test-Ubuntu12-ShuttleA-GTX660-x86-Debug-Trybot
R=tfarina@chromium.org, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/344213003
 2014-06-20 11:29:21 -07:00
mtklein
9e64b78ff6 Revert of Move BenchTimer to tools as Timer (https://codereview.chromium.org/344213003/) 
Reason for revert:
GpuTimer broken

Original issue's description:
> Move BenchTimer to tools as Timer
>
> This breaks a bunch of circular dependencies between tools and gm and bench.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/4ed75287aed6371c6e4a41ffcc78c8a49c9810ed

R=tfarina@chromium.org, mtklein@chromium.org
TBR=mtklein@chromium.org, tfarina@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Author: mtklein@google.com

Review URL: https://codereview.chromium.org/346753003
 2014-06-20 10:43:07 -07:00
mtklein
4ed75287ae Move BenchTimer to tools as Timer 
This breaks a bunch of circular dependencies between tools and gm and bench.

BUG=skia:
R=tfarina@chromium.org, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/344213003
 2014-06-20 10:31:49 -07:00
tfarina
f168b86d7f Remove Sk prefix from some bench classes. 
This idea came while commenting on
https://codereview.chromium.org/343583005/

Since SkBenchmark, SkBenchLogger and SkGMBench are not part of the Skia library,
they should not have the Sk prefix.

BUG=None
TEST=make all
R=mtklein@google.com

Author: tfarina@chromium.org

Review URL: https://codereview.chromium.org/347823004
 2014-06-19 12:32:29 -07:00
tfarina
bcbc1788b4 Refactor how we handle resources path in Tests. 
This idea emerged while doing https://codereview.chromium.org/321723002/
(commit 880914c35c).

BUG=None
TEST=make tests && out/Debug/tests
R=mtklein@google.com

Author: tfarina@chromium.org

Review URL: https://codereview.chromium.org/346453002
 2014-06-18 14:32:49 -07:00
mtklein
30e6e2af14 Add basic stacktrace handler using libunwind. 
This means we will all have to apt-get install libunwind8-dev on Linux.  Mac comes with everything we need already.

BUG=skia:
R=reed@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/343583005
 2014-06-18 11:44:18 -07:00
krajcevski
2dc337c3ae Add non power of two gm for ETC1 bitmap 
R=robertphillips@google.com

Author: krajcevski@google.com

Review URL: https://codereview.chromium.org/316813005
 2014-06-04 09:57:48 -07:00
mtklein
bec3634a4a Android: remove -lcutils dependency 
I believe we no longer depend on this after we ported our atomics to __sync.

Tested by running android_ninja.

BUG=skia:
R=scroggo@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/318493002
 2014-06-03 15:38:18 -07:00
commit-bot@chromium.org
37c772ae2d Reland https://codereview.chromium.org/286903025 
BUG=skia:
R=bensong@google.com, epoger@google.com

Author: kelvinly@google.com

Review URL: https://codereview.chromium.org/304613002

git-svn-id: http://skia.googlecode.com/svn/trunk@14966 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-05-29 17:10:24 +00:00
commit-bot@chromium.org
293a4b367a Revert of PictureBenchmark JSON logging (https://codereview.chromium.org/286903025/) 
Reason for revert:
Broke some Windows builds; see http://skbug.com/2609 ('certain Windows Build-* bots failing since r14905').

Before re-landing with a fix, please send to some of the trybots that failed the first time.

Original issue's description:
> Add JSON logging support to bench_pictures by adding a PictureResultsWriter class (in tools/PictureResultsWriter.h) to process logging information, using a very similar style as bench/ResultsWriter.h
>
> JSON format described in code, above PictureJSONResultsWriter class
>
> BUG=skia:
>
> Committed: http://code.google.com/p/skia/source/detail?r=14906

R=bensong@google.com, jcgregorio@google.com, kelvinly@google.com
TBR=bensong@google.com, jcgregorio@google.com, kelvinly@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2609

Author: epoger@google.com

Review URL: https://codereview.chromium.org/306483010

git-svn-id: http://skia.googlecode.com/svn/trunk@14910 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-05-27 21:51:38 +00:00
commit-bot@chromium.org
3089004cc8 Add JSON logging support to bench_pictures by adding a PictureResultsWriter class (in tools/PictureResultsWriter.h) to process logging information, using a very similar style as bench/ResultsWriter.h 
JSON format described in code, above PictureJSONResultsWriter class

BUG=skia:
R=bensong@google.com, jcgregorio@google.com

Author: kelvinly@google.com

Review URL: https://codereview.chromium.org/286903025

git-svn-id: http://skia.googlecode.com/svn/trunk@14906 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-05-27 20:57:44 +00:00
commit-bot@chromium.org
61744ec1d2 Generate bench/Android.mk from gyp. 
For now, remove json functionality and do not depend on json. This
allows us to build and run until solving skbug.com/2448.

bench/DeferredSurfaceCopyBench.cpp:
Include GrRenderTarget last, so SK_SUPPORT_GPU will be set properly.

bench/ResultsWriter.h:
bench/benchmain.cpp:
Remove JSONResultsWriter when SK_BUILD_JSON_WRITER is not defined,
which is the case for the Android framework build.

gyp/bench.gyp:
Depend on skia and cutils (for android_atomic_inc etc).

gyp/common_conditions.gypi:
Define SK_BUILD_JSON_WRITER when skia_build_json_writer is set.

gyp/common_variables.gypi:
Add a flag for skia_build_json_writer, and set it only when
skia_android_framework is not set.

gyp/jsoncpp.gyp:
Do not build jsoncpp when skia_build_json_writer is not defined.
include/utils/SkJSONCPP.h:
Do not include json headers when SK_BUILD_JSON_WRITER is not defined.

platform_tools/android/bin/gyp_to_android.py:
Generate bench/Android.mk.

platform_tools/android/gyp_gen/gypd_parser.py:
Skip dest_dir when checking for include_dirs.

platform_tools/android/gyp_gen/makefile_writer.py:
Build bench/Android.mk when building external/skia.

platform_tools/android/gyp_gen/tool_makefile_writer.py:
Add a parameter for putting the binary into /data/local/tmp.

BUG=skia:2447
BUG=skia:2448
R=halcanary@google.com, reed@google.com

Author: scroggo@google.com

Review URL: https://codereview.chromium.org/282053002

git-svn-id: http://skia.googlecode.com/svn/trunk@14760 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-05-16 13:15:41 +00:00
commit-bot@chromium.org
8400b23ce6 use BenchTimer, print in µs 
BUG=skia:2378
R=bungeman@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/257563006

git-svn-id: http://skia.googlecode.com/svn/trunk@14405 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-04-28 15:30:02 +00:00
commit-bot@chromium.org
4cd9e2169e Add SkCanvas::writePixels that takes info+pixels directly 
add corresponding methods to device (w/ diff name to avoid colliding with exising virtuals)

BUG=skia:
R=bsalomon@google.com, robertphillips@google.com, junov@google.com, junov@chromium.org

Author: reed@google.com

Review URL: https://codereview.chromium.org/180113010

git-svn-id: http://skia.googlecode.com/svn/trunk@13697 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-03-07 03:25:16 +00:00
commit-bot@chromium.org
38aeb0fd7a DM: also run benches once. 
Also:
  - make GrMemoryPoolBenches threadsafe
  - some tweaks to various DM code
  - rename GM::shortName() to getName() to match benches and tests

On my desktop, (289 GMs, 617 benches) x 4 configs, 227 tests takes 46s in Debug, 14s in Release.  (Still minutes faster than running tests && bench && gm.)  GPU singlethreading is definitely the limiting factor again; going to reexamine whether that's helpful to thread it again.

BUG=skia:
R=reed@google.com, bsalomon@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/178473006

git-svn-id: http://skia.googlecode.com/svn/trunk@13603 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-02-26 23:01:57 +00:00
commit-bot@chromium.org
c22d139808 Initial QuadTree implementation 
In an effort to find a faster bounding box hierarchy than the R-Tree, a QuadTree has been implemented here.
For now, the QuadTree construction is generally faster than the R-Tree and the queries are a bit slower, so overall, SKP local tests showed QuadTree performance similar to the R-Tree performance.

Tests and bench are included in this cl.

At this point, I'd like to be able to commit this in order to more easily use the bots to test multiple configurations and a larger number of SKPs. The R-Tree BBH is still used by default so this change shouldn't affect chromium.

BUG=skia:
R=junov@chromium.org, junov@google.com, senorblanco@google.com, senorblanco@chromium.org, reed@google.com, sugoi@google.com, fmalita@google.com

Author: sugoi@chromium.org

Review URL: https://codereview.chromium.org/131343011

git-svn-id: http://skia.googlecode.com/svn/trunk@13282 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-02-03 18:08:33 +00:00
commit-bot@chromium.org
6adce6783c Allow GMs to be used as benchmarks. Make convex_poly_clip opt in. 
R=reed@google.com

Author: bsalomon@google.com

Review URL: https://codereview.chromium.org/151843002

git-svn-id: http://skia.googlecode.com/svn/trunk@13279 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-02-03 14:48:17 +00:00
commit-bot@chromium.org
78dd91d1af Revert "Revert of Workaround for assertion in NVPR config in bench. (https://codereview.chromium.org/131503007/)" 
add SK_SUPPORT_GPU check

BUG=skia:2042

TBR=robertphillips@google.com

Author: bsalomon@google.com

Review URL: https://codereview.chromium.org/148173005

git-svn-id: http://skia.googlecode.com/svn/trunk@13203 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-01-27 19:52:51 +00:00
commit-bot@chromium.org
594aa5e39d Revert of Workaround for assertion in NVPR config in bench. (https://codereview.chromium.org/131503007/) 
Reason for revert:
broke the build.

Original issue's description:
> Workaround for assertion in NVPR config in bench.
>
> BUG=skia:2078
>
> Committed: http://code.google.com/p/skia/source/detail?r=13196

R=robertphillips@google.com
TBR=robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2078

Author: bsalomon@google.com

Review URL: https://codereview.chromium.org/148473002

git-svn-id: http://skia.googlecode.com/svn/trunk@13199 2bbb7eff-a529-9590-31e7-b0007b416f81
 2014-01-27 18:06:03 +00:00