aboutsummaryrefslogtreecommitdiffhomepage
path: root/bench
Commit message (Collapse)AuthorAge
...
* Rename GrResourceCache2->GrResourceCacheGravatar bsalomon2015-02-11
| | | | | | TBR=robertphillips@google.com Review URL: https://codereview.chromium.org/921453002
* Small change to use a GrGeometryProcessor for all BitmapText draw callsGravatar joshualitt2015-02-11
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/914723002
* Simplify SkBBH::insert APIGravatar mtklein2015-02-10
| | | | | | | | No one's exploiting the ability to take ownership of the array anymore. BUG=skia: Review URL: https://codereview.chromium.org/913833002
* Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of ↵Gravatar mtklein2015-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* nanobench: lazily decode bitmaps in .skps.Gravatar mtklein2015-02-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* add rounded-join option to bigpath benchGravatar reed2015-02-09
| | | | | | | | | BUG=skia: TBR= NOTRY=True ... win bot offline Review URL: https://codereview.chromium.org/909893002
* add bench for very big pathsGravatar reed2015-02-06
| | | | | | | BUG= 455429 TBR= Review URL: https://codereview.chromium.org/909563002
* Add texture create/upload stats and make nanobench have explicit gpu stats flagGravatar bsalomon2015-02-02
| | | | Review URL: https://codereview.chromium.org/891973002
* add bench for building mipmapsGravatar reed2015-01-26
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/873293003
* Collapse consecutive SkTableColorFiltersGravatar cwallez2015-01-26
| | | | | | | | | | | 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
* Update references to skiaperf.com.Gravatar tfarina2015-01-26
| | | | | | | | | The new server is being run in perf.skia.org. BUG=None R=jcgregorio@google.com Review URL: https://codereview.chromium.org/866943003
* remove unused GM flagsGravatar mtklein2015-01-23
| | | | | | | | | | 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
* Spin off GM::runAsBench() from flags.Gravatar mtklein2015-01-23
| | | | | | | | This will let us kill flags. BUG=skia: Review URL: https://codereview.chromium.org/873753002
* Add specialized content key class for resources.Gravatar bsalomon2015-01-23
| | | | Review URL: https://codereview.chromium.org/858123002
* More natural way to serialize GPU tasks and tests.Gravatar mtklein2015-01-21
| | | | | | | | | | | | | 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
* Make SkStream *not* ref counted.Gravatar scroggo2015-01-21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Require budget decision when creating a RenderTarget SkSurface.Gravatar bsalomon2015-01-16
| | | | | | | | | 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
* Sketch DM refactor.Gravatar mtklein2015-01-15
| | | | | | | | | | | | | | | | | | | 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
* Revert of Sketch DM refactor. (patchset #45 id:850001 of ↵Gravatar mtklein2015-01-15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Sketch DM refactor.Gravatar mtklein2015-01-15
| | | | | | | | | | | | | | | | | 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
* Make uncached textures uncached from the get go.Gravatar bsalomon2015-01-14
| | | | | | | | 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
* Fix up all the easy virtual ... SK_OVERRIDE cases.Gravatar mtklein2015-01-09
| | | | | | | | | | | | 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
* PictureNestingBench: stay in ints.Gravatar mtklein2015-01-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/784173004
* Remove SkTileGrid (except for TileGridInfo).Gravatar mtklein2015-01-09
| | | | | | | | TBR=reed@google.com BUG=skia:3085 Review URL: https://codereview.chromium.org/845623002
* add ImageGenerator::NewFromData to porting layerGravatar reed2015-01-07
| | | | | | BUG=skia:3275 Review URL: https://codereview.chromium.org/834633006
* Cleanup: More override fixes - another round.Gravatar tfarina2015-01-05
| | | | | | | | BUG=skia:3075 TEST=ninja -C out/Debug TBR=reed@google.com Review URL: https://codereview.chromium.org/831113002
* Add a simpler key type for scratch resource keys.Gravatar bsalomon2014-12-30
| | | | | | BUG=skia:2889 Review URL: https://codereview.chromium.org/815833004
* Cleanup: Remove a bunch of SkFontHost.h includes (unused).Gravatar tfarina2014-12-18
| | | | | | | | | | 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
* fix last warnings on w64 and turn on w.a.e.Gravatar bsalomon2014-12-15
| | | | Review URL: https://codereview.chromium.org/801413002
* Remove SkCanvas::drawBitmapMatrix()Gravatar Florin Malita2014-12-10
| | | | | | R=mtklein@google.com, reed@google.com, robertphillips@google.com Review URL: https://codereview.chromium.org/789033002
* Add bench to measure blur rects performanceGravatar qiankun.miao2014-12-09
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/787913002
* Update nanobench so the non-MPD path doesn't permit layer hoistingGravatar robertphillips2014-12-09
| | | | Review URL: https://codereview.chromium.org/787923002
* Switch non-MPD nanobench path to use a separate canvas per tileGravatar robertphillips2014-12-09
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Don't upload metrics we don't want to track.Gravatar mtklein2014-12-05
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/758853004
* nanobench: upload peak memory usage as its own trace.Gravatar mtklein2014-12-04
| | | | | | | | | | | | | 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
* Upload picture byte size and op count metrics for SKP recording.Gravatar mtklein2014-12-04
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix SKPBench tiling so MPD and non-MPD matchGravatar robertphillips2014-12-04
| | | | | | | | | | 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
* Turn on MPD threading in nanobench.Gravatar mtklein2014-12-03
| | | | | | | | | | 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
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-30 05:24:59 +0000