aboutsummaryrefslogtreecommitdiffhomepage
path: root/bench
Commit message (Collapse)AuthorAge
* use Sk2s for conicsGravatar reed2015-03-20
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1025033002
* Only use 256x256 tiles on hd2000 nanobench botsGravatar egdaniel2015-03-20
| | | | | | | | | | | Initial experiments did show that the 256 tile size fixed the hd2000 win7 nanobot failures. However it did not have any effect on other bots, so this change is to move back to the larger tile size on all bots expect for the hd2000. BUG=skia: Review URL: https://codereview.chromium.org/1022083002
* use Sk2s for EvalQuadTangent and ChopQuadAtGravatar reed2015-03-20
| | | | | | | | cloned from https://codereview.chromium.org/1026633002/ BUG=skia: Review URL: https://codereview.chromium.org/1024873003
* Move skp nanobench tile size back to 256x256 to see if it fixes nanobench ↵Gravatar egdaniel2015-03-19
| | | | | | | | | | | | | | crashes Going back to old nanobench tile size to see if the increase to tile is what has been causing recent nanobench crashes. The crashes seem very nondeterministic and hard to debug manually. 256x256 is too small of a tile to give accurate gpu results but if this fixes we can try some compromise in the middle BUG=skia: Review URL: https://codereview.chromium.org/1022823003
* alt SkEvalQuadAt that returns its answer, using Sk2fGravatar reed2015-03-19
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/1011493003
* Revert of replace SkFixedDiv impl with native 64bit math (patchset #2 ↵Gravatar reed2015-03-19
| | | | | | | | | | | | | | | | | | | | | | | | | id:20001 of https://codereview.chromium.org/1022543003/) Reason for revert: http://build.chromium.org/p/tryserver.blink/builders/linux_blink_rel/builds/53096 layouttests failures Original issue's description: > replace SkFixedDiv impl with native 64bit math > > BUG=skia: > TBR= > > Committed: https://skia.googlesource.com/skia/+/7c44ca926bf42b3b2e56131f250c0fd58f87ac71 TBR= NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/1018523008
* replace SkFixedDiv impl with native 64bit mathGravatar reed2015-03-18
| | | | | | | BUG=skia: TBR= Review URL: https://codereview.chromium.org/1022543003
* Remove uniqueID from all filter serialization.Gravatar senorblanco2015-03-18
| | | | | | | | | | | | (This is essentially a revert of https://codereview.chromium.org/503833002/.) This was necessary back when SkPaint was flattened even for in-process use. Now that we only flatten SkPaint for cross-process use, there's no need to serialize UniqueIDs. Note: SkDropShadowImageFilter is being constructed with a croprect and UniqueID (of 0) in Blink. I've made the uniqueID param default to 0 temporarily, until this rolls in and Blink can be changed. (Blink can't be changed first, since unlike the other filters, there's no constructor that takes a cropRect but not a uniqueID.) BUG=skia: Review URL: https://codereview.chromium.org/1019493002
* SkPaint::FilterLevel -> SkFilterQualityGravatar reed2015-03-16
| | | | | | | | | clone (+rebase) of https://codereview.chromium.org/1009183002/ BUG=skia: TBR=scroggo@google.com Review URL: https://codereview.chromium.org/1014533004
* DM: display current memory usage (instead of peak) when available.Gravatar mtklein2015-03-12
| | | | | | | | | | | | | | | Seems strictly more useful. This implements Mac and Windows, which seemed easy. Don't know how to do this on Linux yet. BUG=skia: CQ_EXTRA_TRYBOTS=client.skia:Test-Mac10.9-MacMini6.2-HD4000-x86_64-Debug-Trybot NOTREECHECKS=true TBR=halcanary@google.com Review URL: https://codereview.chromium.org/990723002
* Increase default tile sizes in nanobenchGravatar bsalomon2015-03-05
| | | | | | R=mtklein@google.com Review URL: https://codereview.chromium.org/982863003
* 4-at-a-time SkPMColor -> SkPMFloat API.Gravatar mtklein2015-03-05
| | | | | | | | | | | | Please see if this looks usable. It may even give a perf boost if you use it, even without custom implementations for each instruction set. I've been trying this morning to beat this naive loop implementation, but so far no luck with either _SSE2.h or _SSSE3.h. It's possible this is an artifact of the microbenchmark, because we're not doing anything between the conversions. I'd like to see how this fits into real code, what assembly's generated, what the hot spots are, etc. I've updated the tests to test these new APIs, and splintered off a pair of new benchmarks that use the new APIs. This required some minor rejiggering in the benches. BUG=skia: Review URL: https://codereview.chromium.org/978213003
* Update SkPMFloat API a bit.Gravatar mtklein2015-03-04
| | | | | | | | | | | Instead of set(SkPMColor), add a constructor SkPMFloat(SkPMColor). Replace setA(), setR(), etc. with a 4 float constructor. And, promise to stick to SkPMColor order. BUG=skia: Review URL: https://codereview.chromium.org/977773002
* Trim the fat off SkPMFloat bench.Gravatar mtklein2015-03-03
| | | | | | | | | | | | This bench was ~75% overhead, ~25% good bench. It is now just about the opposite: about 30% of the runtime is loop and random number overhead, and about 70% of the time is spent doing SkPMColor <-> SkPMFloat work. BUG=skia: NOPRESUBMIT=true Review URL: https://codereview.chromium.org/968133005
* Notify resource caches when pixelref genID goes staleGravatar reed2015-02-24
| | | | | | | | patch from issue 954443002 at patchset 40001 (http://crrev.com/954443002#ps40001) BUG=skia: Review URL: https://codereview.chromium.org/950363002
* Sketch SkPMFloatGravatar mtklein2015-02-23
| | | | | | | | | | | | BUG=skia: Committed: https://skia.googlesource.com/skia/+/50d2b3114b3e59dc84811881591bf25b2c1ecb9f CQ_EXTRA_TRYBOTS=client.skia.compile:Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon-Trybot http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon/builds/2120/steps/build%20most/logs/stdio Review URL: https://codereview.chromium.org/936633002
* Revert of Sketch SkPMFloat (patchset #15 id:270001 of ↵Gravatar mtklein2015-02-23
| | | | | | | | | | | | | | | | | | | | | | https://codereview.chromium.org/936633002/) Reason for revert: http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-GCC4.8-Arm7-Release-Android_Neon/builds/2120/steps/build%20most/logs/stdio Original issue's description: > Sketch SkPMFloat > > BUG=skia: > > Committed: https://skia.googlesource.com/skia/+/50d2b3114b3e59dc84811881591bf25b2c1ecb9f TBR=reed@google.com,msarrett@google.com,mtklein@chromium.org NOPRESUBMIT=true NOTREECHECKS=true NOTRY=true BUG=skia: Review URL: https://codereview.chromium.org/952453004
* Sketch SkPMFloatGravatar mtklein2015-02-23
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/936633002
* Rename GrContentKey to GrUniqueKeyGravatar bsalomon2015-02-19
| | | | Review URL: https://codereview.chromium.org/940463006
* Split out methods in GrGpuResource::CacheAccess that can be called outside ↵Gravatar bsalomon2015-02-13
| | | | | | of the cache. Review URL: https://codereview.chromium.org/923143002
* Adding new benchmark to test image decoding performance.Gravatar msarett2015-02-13
| | | | | | BUG=skia: Review URL: https://codereview.chromium.org/918673002
* 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
generated by cgit v1.2.3 (git 2.39.1) at 2024-10-19 00:39:25 +0000