| Commit message (Collapse) | Author | Age |
|
|
|
|
|
| |
R=mtklein@google.com, reed@google.com, robertphillips@google.com
Review URL: https://codereview.chromium.org/789033002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/787913002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/787923002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/758853004
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
BUG=skia:2889
Committed: https://skia.googlesource.com/skia/+/91175f19664a62851da4ca4e0984a7c7c45b258f
Review URL: https://codereview.chromium.org/747043004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/745383003
|
|
|
|
|
|
| |
BUG=skia:2889
Review URL: https://codereview.chromium.org/754833002
|
|
|
|
|
|
| |
BUG=skia:2889
Review URL: https://codereview.chromium.org/747043004
|
|
|
|
|
|
| |
This is cleanup for (Add MultiPictureDraw to nanobench - https://codereview.chromium.org/731973005/)
Review URL: https://codereview.chromium.org/730343003
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Propagate a bunch of constant parameters through.
- Delete code that's not used when bulk loading.
- Allocate all Nodes together.
- Stay in SkRect.
Doing a single malloc for the nodes can't not have improved memory usage.
Looks like this might improve record performance ~5%, probably mostly from
staying in SkRects. This finally dethrones building the BBH as the hot spot.
(Now it's mapping user bounds back to device bounds and adjusting for paints.)
Recording time changes from my MBP:
desk_rectangletransition.skp 11.5us -> 11.7us 1x
desk_forecastio.skp 115us -> 114us 0.98x
desk_booking.skp 550us -> 541us 0.98x
tabl_mercurynews.skp 176us -> 173us 0.98x
tabl_hsfi.skp 294us -> 287us 0.98x
desk_wordpress.skp 351us -> 343us 0.98x
tabl_worldjournal.skp 439us -> 426us 0.97x
tabl_gmail.skp 20.3us -> 19.7us 0.97x
desk_youtubetvvideo.skp 10.8us -> 10.4us 0.97x
desk_googleplus.skp 1.1ms -> 1.07ms 0.97x
tabl_slashdot.skp 106us -> 103us 0.97x
desk_jsfiddlebigcar.skp 26.7us -> 25.7us 0.96x
tabl_techmeme.skp 95.4us -> 91.7us 0.96x
tabl_deviantart.skp 133us -> 127us 0.96x
desk_pinterest.skp 40.6us -> 38.9us 0.96x
desk_carsvg.skp 195us -> 187us 0.96x
tabl_engadget.skp 376us -> 359us 0.96x
tabl_sahadan.skp 60.5us -> 57.5us 0.95x
tabl_culturalsolutions.skp 255us -> 242us 0.95x
tabl_gspro.skp 58.3us -> 55.5us 0.95x
desk_linkedin.skp 146us -> 138us 0.94x
desk_ebay.skp 192us -> 181us 0.94x
tabl_cnn.skp 467us -> 440us 0.94x
desk_jsfiddlehumperclip.skp 29.9us -> 28.1us 0.94x
desk_tigersvg.skp 43.2us -> 40.5us 0.94x
desk_yahooanswers.skp 131us -> 123us 0.94x
desk_googlespreadsheetdashed.skp 1.18ms -> 1.11ms 0.94x
desk_blogger.skp 193us -> 181us 0.94x
tabl_mozilla.skp 1.82ms -> 1.7ms 0.94x
tabl_mlb.skp 145us -> 136us 0.93x
mobi_wikipedia.skp 577us -> 539us 0.93x
tabl_frantzen.skp 54.1us -> 50.4us 0.93x
desk_baidu.skp 87.9us -> 81.9us 0.93x
desk_techcrunch.skp 224us -> 209us 0.93x
desk_sfgate.skp 206us -> 192us 0.93x
tabl_ukwsj.skp 269us -> 250us 0.93x
desk_facebook.skp 316us -> 293us 0.93x
desk_gmailthread.skp 205us -> 190us 0.93x
tabl_googlecalendar.skp 158us -> 147us 0.93x
tabl_digg.skp 382us -> 354us 0.93x
desk_amazon.skp 106us -> 98.5us 0.93x
tabl_androidpolice.skp 693us -> 642us 0.93x
tabl_nytimes.skp 206us -> 191us 0.92x
desk_gws.skp 124us -> 114us 0.92x
desk_youtube.skp 255us -> 235us 0.92x
tabl_cuteoverload.skp 583us -> 537us 0.92x
desk_oldinboxapp.skp 18us -> 16.6us 0.92x
desk_mobilenews.skp 297us -> 273us 0.92x
tabl_pravda.skp 168us -> 154us 0.92x
tabl_vnexpress.skp 236us -> 217us 0.92x
desk_css3gradients.skp 202us -> 185us 0.92x
tabl_gamedeksiam.skp 508us -> 464us 0.91x
desk_wowwiki.skp 1.02ms -> 929us 0.91x
desk_espn.skp 209us -> 191us 0.91x
desk_chalkboard.skp 315us -> 284us 0.9x
desk_mapsvg.skp 607us -> 543us 0.89x
desk_pokemonwiki.skp 5.18ms -> 4.62ms 0.89x
desk_samoasvg.skp 335us -> 298us 0.89x
desk_youtubetvbrowse.skp 10.1us -> 8.59us 0.85x
BUG=skia:3085, skia:2834
Review URL: https://codereview.chromium.org/734723002
|
|
|
|
|
|
|
|
|
|
| |
Removes work done by the constructors of picture_nesting benches,
and moves the work to the Benchmark::onPreDraw override.
This avoids PictureNesting::sierpinsky showing up in profile traces
when profiling other benches.
Review URL: https://codereview.chromium.org/725523002
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2889
TBR=robertphillips@google.com
NOTRY=true
Review URL: https://codereview.chromium.org/729683002
|
|
|
|
|
|
|
|
|
|
| |
BUG=skia:2889
Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6
Committed: https://skia.googlesource.com/skia/+/407aa584d183c1bf314f5defd1cf0202e8a96c89
Review URL: https://codereview.chromium.org/716143004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:120001 of https://codereview.chromium.org/716143004/)
Reason for revert:
broken again
Original issue's description:
> Replace GrResourceCache with GrResourceCache2.
>
> BUG=skia:2889
>
> Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6
>
> Committed: https://skia.googlesource.com/skia/+/407aa584d183c1bf314f5defd1cf0202e8a96c89
TBR=robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2889
Review URL: https://codereview.chromium.org/726913002
|
|
|
|
|
|
|
|
| |
BUG=skia:2889
Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6
Review URL: https://codereview.chromium.org/716143004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
id:100001 of https://codereview.chromium.org/716143004/)
Reason for revert:
Breaking stuff
Original issue's description:
> Replace GrResourceCache with GrResourceCache2.
>
> BUG=skia:2889
>
> Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6
TBR=robertphillips@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2889
Review URL: https://codereview.chromium.org/715333003
|
|
|
|
|
|
| |
BUG=skia:2889
Review URL: https://codereview.chromium.org/716143004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
BUG=skia:2889
Review URL: https://codereview.chromium.org/702413003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
On my laptop:
maxrss loops min median mean max stddev samples config bench
37M 1 14ms 14.2ms 14.6ms 18.2ms 9% ▁█▁▁▁▁▂▂▂▁ gpu tiled_playback_tilegrid_tiled
40M 1 17ms 17.2ms 17.2ms 17.6ms 1% ▆▃▁█▄▇▂▁▁▁ gpu tiled_playback_tilegrid_random
40M 1 14.6ms 14.9ms 15.8ms 19.1ms 11% ▂▁▁▁▁▁▁█▅█ gpu tiled_playback_rtree_tiled
43M 1 16.5ms 16.7ms 16.8ms 17.4ms 1% ▂▃▅█▃▂▁▃▃▂ gpu tiled_playback_rtree_random
43M 1 15.9ms 16.1ms 16.5ms 18.7ms 6% ▁▁█▇▁▁▁▂▁▁ gpu tiled_playback_none_tiled
44M 1 17.9ms 17.9ms 18ms 18.1ms 1% ▂▁▅▁▇▃▁▂█▇ gpu tiled_playback_none_random
TileGrid and RTree perform pretty much the same, both beating no BBH.
BUG=skia:3085
Review URL: https://codereview.chromium.org/699313006
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tests path_hairline_{small,big}_AA_conic were calling the test
function with NVPR. This caused a warning in nanobench.
The here removed hunk comes from commit referring to skia:2042 ("Enable
NVPR by default"). This is a workaround for a bug. The bug is fixed by
the commit referring to skia:2078 ("Logan bot fails NVPR assertion in
bench").
The proper fix is indeed make sure that path renderer chain ends up
trying software path renderer, if the path contains conics and is a
hairline.
The removed hunk refers also to skia:2033 ("Figure out what is happening
with conic path segments in NVPR"). The above solution is correct also in case
NVPR would support conics, as NVPR would not still support hairlines.
BUG=skia:2078
Review URL: https://codereview.chromium.org/685213005
|
|
|
|
|
|
| |
BUG=skia:2889
Review URL: https://codereview.chromium.org/707493002
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds a new config to test distance field text.
Clean up some flags and #defines to read "distance field text",
not "distance field fonts" to be consistent with Chromium
NOTREECHECKS=true
Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960b
Review URL: https://codereview.chromium.org/699453005
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(patchset #2 id:20001 of https://codereview.chromium.org/699453005/)
Reason for revert:
Not compiling in ANGLE build
Original issue's description:
> Get gpudft support working in dm, gm, nanobench and bench_pictures
>
> Adds a new config to test distance field text.
> Clean up some flags and #defines to read "distance field text",
> not "distance field fonts" to be consistent with Chromium
>
> NOTREECHECKS=true
>
> Committed: https://skia.googlesource.com/skia/+/06ba179838ba4fe187cf290750aeeb4a02a2960b
TBR=bsalomon@google.com,mtklein@google.com,reed@google.com
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/707723005
|
|
|
|
|
|
|
|
|
|
| |
Adds a new config to test distance field text.
Clean up some flags and #defines to read "distance field text",
not "distance field fonts" to be consistent with Chromium
NOTREECHECKS=true
Review URL: https://codereview.chromium.org/699453005
|
|
|
|
|
|
|
|
| |
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/709473002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/698163004
|
|
|
|
|
|
|
|
| |
Looks like a fairly large recording speed win with no playback cost.
BUG=skia:
Review URL: https://codereview.chromium.org/653023003
|
|
|
|
| |
Review URL: https://codereview.chromium.org/682223002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- The expected case is now a single bulk-load insert() call instead of N;
- reserve() and flushDeferredInserts() can fold into insert() now;
- SkBBH subclasses may take ownership of the bounds
This appears to be a performance no-op on both my Mac and N5. I guess
even the simplest indirect branch predictor ("same as last time") can predict
the repeated virtual calls to SkBBH::insert() perfectly.
BUG=skia:
Review URL: https://codereview.chromium.org/670213002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/680553002
|
|
|
|
|
|
|
|
|
|
| |
id:120001 of https://codereview.chromium.org/664783004/)"
This reverts commit 430b795cc8a1cdbddd8fdc5511a3a523348937f7 and adds suppressions.
BUG=skia:
Review URL: https://codereview.chromium.org/673023002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/664783004/)
Reason for revert:
Many GMs fixed. Needs rebaseline, perhaps layout test rebaselines.
Original issue's description:
> create shaderproc for nofilter-opaque-dx
>
>
> speedup nofilter
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/a40a276bcee2246439dcf816273c1307f5c3c69f
TBR=djsollen@google.com,reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/656913005
|
|
|
|
|
|
|
|
| |
speedup nofilter
BUG=skia:
Review URL: https://codereview.chromium.org/664783004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a new enum to differentiate between a complete decode and a
partial decode (with the third value being failure). Return this
value from SkImageDecoder::onDecode (in all subclasses, plus
SkImageDecoder_empty) and ::decode.
For convenience, if the enum is treated as a boolean, success and
partial success are both considered true.
Note that the static helper functions (DecodeFile etc) still return
true and false (for one thing, this allows us to continue to use
SkImageDecoder::DecodeMemory as an SkPicture::InstallPixelRefProc in
SkPicture::CreateFromStream).
Also correctly report failure in SkASTCImageDecoder::onDecode when
SkTextureCompressor::DecompressBufferFromFormat fails.
BUG=skia:3037
BUG:b/17419670
Review URL: https://codereview.chromium.org/647023006
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add a unique-per-subclass namespace tag to make Keys from different
domains comparable.
Also drop the SkPictureShader cache and convert to using the global
resource cache instead.
R=reed@google.com,mtklein@google.com,robertphillips@google.com
Review URL: https://codereview.chromium.org/668223002
|
|
|
|
|
|
|
|
| |
(This CL will certainly trigger performance regression alerts. Tiled drawing is slower than non-tiled drawing.)
BUG=skia:
Review URL: https://codereview.chromium.org/669983002
|