AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
15,835 Commits 1 Branch 0 Tags 544 MiB
0004e7db42
Commit Graph

1053 Commits

Author SHA1 Message Date
tfarina
0004e7db42 Update references to skiaperf.com. 
The new server is being run in perf.skia.org.

BUG=None
R=jcgregorio@google.com

Review URL: https://codereview.chromium.org/866943003
 2015-01-26 06:47:55 -08:00
mtklein
1c4029296f remove unused GM flags 
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
 2015-01-23 11:07:08 -08:00
mtklein
cf5d9c993d Spin off GM::runAsBench() from flags. 
This will let us kill flags.

BUG=skia:

Review URL: https://codereview.chromium.org/873753002
 2015-01-23 10:31:45 -08:00
bsalomon
24db3b1c35 Add specialized content key class for resources. 
Review URL: https://codereview.chromium.org/858123002
 2015-01-23 04:24:05 -08:00
mtklein
55e88b226c More natural way to serialize GPU tasks and tests. 
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
 2015-01-21 15:50:13 -08:00
scroggo
a1193e4b0e Make SkStream *not* ref counted. 
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
 2015-01-21 12:09:53 -08:00
bsalomon
afe3005be3 Require budget decision when creating a RenderTarget SkSurface. 
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
 2015-01-16 07:32:33 -08:00
mtklein
748ca3bf2d 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

Review URL: https://codereview.chromium.org/788243008
 2015-01-15 10:56:12 -08:00
mtklein
114c3cd054 Revert of Sketch DM refactor. (patchset #45 id:850001 of 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
 2015-01-15 10:15:02 -08:00
mtklein
709d2c3e50 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

Review URL: https://codereview.chromium.org/788243008
 2015-01-15 08:30:25 -08:00
bsalomon
5236cf480d Make uncached textures uncached from the get go. 
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
 2015-01-14 10:42:08 -08:00
mtklein
72c9faab45 Fix up all the easy virtual ... SK_OVERRIDE cases. 
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
 2015-01-09 10:06:40 -08:00
mtklein
d0256a2fbc PictureNestingBench: stay in ints. 
BUG=skia:

Review URL: https://codereview.chromium.org/784173004
 2015-01-09 08:33:36 -08:00
mtklein
703dd2ed18 Remove SkTileGrid (except for TileGridInfo). 
TBR=reed@google.com

BUG=skia:3085

Review URL: https://codereview.chromium.org/845623002
 2015-01-09 06:41:48 -08:00
reed
5965c8ae4e add ImageGenerator::NewFromData to porting layer 
BUG=skia:3275

Review URL: https://codereview.chromium.org/834633006
 2015-01-07 18:04:45 -08:00
tfarina
aa458fb20a Cleanup: More override fixes - another round. 
BUG=skia:3075
TEST=ninja -C out/Debug
TBR=reed@google.com

Review URL: https://codereview.chromium.org/831113002
 2015-01-05 17:18:51 -08:00
bsalomon
7775c85611 Add a simpler key type for scratch resource keys. 
BUG=skia:2889

Review URL: https://codereview.chromium.org/815833004
 2014-12-30 12:50:52 -08:00
tfarina
1348dfd5df Cleanup: Remove a bunch of SkFontHost.h includes (unused). 
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
 2014-12-18 05:48:53 -08:00
bsalomon
0aa5cea869 fix last warnings on w64 and turn on w.a.e. 
Review URL: https://codereview.chromium.org/801413002
 2014-12-15 09:13:35 -08:00
Florin Malita
c54d8db4d1 Remove SkCanvas::drawBitmapMatrix() 
R=mtklein@google.com, reed@google.com, robertphillips@google.com

Review URL: https://codereview.chromium.org/789033002
 2014-12-10 12:02:16 -05:00
qiankun.miao
e18a530afd Add bench to measure blur rects performance 
BUG=skia:

Review URL: https://codereview.chromium.org/787913002
 2014-12-09 17:47:05 -08:00
robertphillips
e451c4df73 Update nanobench so the non-MPD path doesn't permit layer hoisting 
Review URL: https://codereview.chromium.org/787923002
 2014-12-09 10:28:00 -08:00
robertphillips
a3e52724ac Switch non-MPD nanobench path to use a separate canvas per tile 
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
 2014-12-09 10:27:54 -08:00
mtklein
5a8fc33320 Don't upload metrics we don't want to track. 
BUG=skia:

Review URL: https://codereview.chromium.org/758853004
 2014-12-05 07:25:16 -08:00
mtklein
e109145bf3 nanobench: upload peak memory usage as its own trace. 
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
 2014-12-04 10:47:02 -08:00
mtklein
051e56df8f Upload picture byte size and op count metrics for SKP recording. 
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
 2014-12-04 08:46:51 -08:00
robertphillips
63242d7d24 Fix SKPBench tiling so MPD and non-MPD match 
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
 2014-12-04 08:31:03 -08:00
mtklein
4f10844149 Turn on MPD threading in nanobench. 
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
 2014-12-03 13:07:39 -08:00
mtklein
535776eb28 Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of https://codereview.chromium.org/743613005/) 
Reason for revert:
Some bots crashing.

Original issue's description:
> nanobench: lazily decode bitmaps in .skps.
>
> This cuts down on tool overhead when running something like recording only,
>     $ out/Release/nanobench --match skp --config nonrendering
> which doesn't usually ever need to decode the images.
>
> The actual measurements for recording don't change, as the decode is not in the timed section.  It just skips irrelevant code, removing it from the profile and making the tool run faster.
>
> This does, however, make a significant difference for playback speed.  Most skps draw faster with this patch, some slower.  I don't really have a good intuition for what's going on here.  There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded.  Ideas?  Is this perhaps because we're now blitting from smaller, partially decoded source images?
>
> ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log
>                    tabl_slashdot.skp_1	2.76ms -> 4.33ms	1.57x
>                tabl_slashdot.skp_1_mpd	2.79ms -> 4.07ms	1.46x
>                     tabl_sahadan.skp_1	3.41ms -> 4.87ms	1.43x
>                  tabl_googleblog.skp_1	1.52ms -> 2.05ms	1.35x
>                tabl_techmeme.skp_1_mpd	1.14ms -> 1.51ms	1.32x
>                tabl_transformice.skp_1	2.61ms -> 3.43ms	1.31x
>                 tabl_sahadan.skp_1_mpd	3.54ms -> 4.48ms	1.26x
>                    tabl_techmeme.skp_1	1.01ms -> 1.27ms	1.26x
>                 tabl_nytimes.skp_1_mpd	   1ms -> 1.23ms	1.23x
>            tabl_worldjournal.skp_1_mpd	1.98ms -> 2.43ms	1.23x
>                  tabl_pravda.skp_1_mpd	2.05ms -> 2.51ms	1.22x
>            tabl_transformice.skp_1_mpd	2.75ms -> 3.19ms	1.16x
>                     tabl_nytimes.skp_1	 874us -> 1.01ms	1.15x
>                      tabl_pravda.skp_1	1.83ms -> 1.99ms	1.09x
>                tabl_worldjournal.skp_1	1.76ms -> 1.91ms	1.09x
>                 desk_wowwiki.skp_1_mpd	 3.7ms ->  3.9ms	1.05x
>                        tabl_digg.skp_1	3.99ms -> 4.16ms	1.04x
>                   tabl_ukwsj.skp_1_mpd	   3ms -> 3.12ms	1.04x
>                     desk_booking.skp_1	3.74ms -> 3.81ms	1.02x
>     desk_googlespreadsheetdashed.skp_1	10.6ms -> 10.6ms	1x
>                       tabl_ukwsj.skp_1	2.88ms -> 2.89ms	1x
> desk_googlespreadsheetdashed.skp_1_mpd	11.8ms -> 11.8ms	1x
>      desk_jsfiddlehumperclip.skp_1_mpd	 891us ->  888us	1x
>           desk_googlespreadsheet.skp_1	4.65ms -> 4.62ms	0.99x
>                   tabl_gspro.skp_1_mpd	1.97ms -> 1.94ms	0.99x
>                 desk_booking.skp_1_mpd	 4.1ms ->    4ms	0.98x
>                      desk_carsvg.skp_1	18.2ms -> 17.7ms	0.97x
>             desk_gmailthread.skp_1_mpd	2.81ms -> 2.73ms	0.97x
>                desk_tigersvg.skp_1_mpd	19.5ms -> 18.9ms	0.97x
>                      desk_mapsvg.skp_1	88.4ms -> 85.6ms	0.97x
>                    tabl_cnet.skp_1_mpd	1.43ms -> 1.38ms	0.97x
>              desk_jsfiddlebigcar.skp_1	1.26ms -> 1.22ms	0.96x
>                         desk_gws.skp_1	1.87ms ->  1.8ms	0.96x
>                    desk_linkedin.skp_1	2.07ms -> 1.98ms	0.96x
>              tabl_deviantart.skp_1_mpd	 118ms ->  113ms	0.96x
>                        tabl_cnet.skp_1	 1.2ms -> 1.14ms	0.95x
>           tabl_androidpolice.skp_1_mpd	5.95ms -> 5.63ms	0.95x
>                      desk_sfgate.skp_1	1.75ms -> 1.64ms	0.94x
>                     desk_twitter.skp_1	  74ms -> 69.6ms	0.94x
>                 desk_youtube.skp_1_mpd	3.17ms -> 2.96ms	0.93x
>                 desk_gmailthread.skp_1	2.73ms -> 2.54ms	0.93x
>             desk_silkfinance.skp_1_mpd	1.71ms -> 1.59ms	0.93x
>          desk_jsfiddlebigcar.skp_1_mpd	1.45ms -> 1.35ms	0.93x
>             desk_pokemonwiki.skp_1_mpd	2.72ms -> 2.51ms	0.92x
>                     desk_gws.skp_1_mpd	2.14ms -> 1.98ms	0.92x
>                  desk_googlehome.skp_1	 563us ->  517us	0.92x
>                        desk_espn.skp_1	4.24ms -> 3.89ms	0.92x
>           tabl_culturalsolutions.skp_1	12.7ms -> 11.6ms	0.91x
>                  desk_sfgate.skp_1_mpd	1.91ms -> 1.74ms	0.91x
>                        tabl_hsfi.skp_1	1.06ms ->  966us	0.91x
>                desk_samoasvg.skp_1_mpd	10.5ms -> 9.47ms	0.91x
>                desk_facebook.skp_1_mpd	 3.8ms -> 3.43ms	0.9x
>                     desk_youtube.skp_1	3.52ms -> 3.14ms	0.89x
>                    desk_ebay.skp_1_mpd	2.95ms -> 2.62ms	0.89x
>                    desk_samoasvg.skp_1	10.9ms -> 9.66ms	0.89x
>       desk_googlespreadsheet.skp_1_mpd	5.59ms -> 4.94ms	0.88x
>                  desk_mapsvg.skp_1_mpd	 100ms -> 87.9ms	0.88x
>                    desk_espn.skp_1_mpd	 4.7ms -> 4.12ms	0.88x
>               desk_wordpress.skp_1_mpd	1.92ms -> 1.68ms	0.87x
>                  tabl_deviantart.skp_1	 140ms ->  122ms	0.87x
>            tabl_cuteoverload.skp_1_mpd	4.41ms -> 3.83ms	0.87x
>                    desk_tigersvg.skp_1	19.6ms ->   17ms	0.87x
>              tabl_googlecalendar.skp_1	4.01ms -> 3.44ms	0.86x
>                     desk_blogger.skp_1	2.49ms -> 2.14ms	0.86x
>              desk_chalkboard.skp_1_mpd	52.7ms ->   45ms	0.85x
>                     desk_weather.skp_1	2.88ms -> 2.46ms	0.85x
>                  desk_chalkboard.skp_1	  51ms -> 43.4ms	0.85x
>                desk_yahooanswers.skp_1	2.74ms -> 2.32ms	0.85x
>              desk_forecastio.skp_1_mpd	1.26ms -> 1.07ms	0.85x
>               tabl_androidpolice.skp_1	5.18ms -> 4.34ms	0.84x
>            desk_yahooanswers.skp_1_mpd	3.44ms -> 2.85ms	0.83x
>                     tabl_cnn.skp_1_mpd	2.59ms -> 2.15ms	0.83x
>                   desk_pinterest.skp_1	2.69ms -> 2.22ms	0.83x
>                    tabl_hsfi.skp_1_mpd	 1.6ms -> 1.32ms	0.82x
>       tabl_culturalsolutions.skp_1_mpd	13.8ms -> 11.3ms	0.82x
>                 desk_twitter.skp_1_mpd	76.6ms ->   63ms	0.82x
>                        desk_ebay.skp_1	3.11ms -> 2.51ms	0.81x
>                     tabl_mlb.skp_1_mpd	3.17ms -> 2.53ms	0.8x
>                     tabl_mozilla.skp_1	2.42ms -> 1.91ms	0.79x
>                 desk_pokemonwiki.skp_1	2.84ms -> 2.22ms	0.78x
>                  desk_carsvg.skp_1_mpd	23.3ms -> 17.8ms	0.77x
>                     desk_wowwiki.skp_1	4.21ms -> 3.21ms	0.76x
>                      desk_amazon.skp_1	 963us ->  728us	0.76x
>               desk_css3gradients.skp_1	2.58ms -> 1.92ms	0.74x
>                tabl_cuteoverload.skp_1	4.55ms -> 3.38ms	0.74x
>                         tabl_cnn.skp_1	3.13ms -> 2.29ms	0.73x
>              tabl_googleblog.skp_1_mpd	2.32ms ->  1.7ms	0.73x
>                  desk_mobilenews.skp_1	3.65ms -> 2.61ms	0.71x
>                  desk_googleplus.skp_1	3.76ms -> 2.66ms	0.71x
>                 tabl_mozilla.skp_1_mpd	2.88ms -> 2.03ms	0.71x
>               desk_pinterest.skp_1_mpd	3.17ms -> 2.21ms	0.7x
>           desk_css3gradients.skp_1_mpd	2.98ms -> 2.07ms	0.69x
>                 desk_silkfinance.skp_1	2.06ms -> 1.42ms	0.69x
>                    desk_facebook.skp_1	 4.5ms -> 3.07ms	0.68x
>              desk_mobilenews.skp_1_mpd	4.05ms -> 2.73ms	0.68x
>                   desk_baidu.skp_1_mpd	2.73ms -> 1.81ms	0.66x
>                 desk_weather.skp_1_mpd	3.93ms ->  2.5ms	0.64x
>                   desk_wordpress.skp_1	2.15ms -> 1.36ms	0.63x
>              desk_googlehome.skp_1_mpd	1.02ms ->  605us	0.59x
>                    desk_fontwipe.skp_1	 722us ->  402us	0.56x
>                desk_fontwipe.skp_1_mpd	 897us ->  486us	0.54x
>                       desk_baidu.skp_1	3.02ms ->  1.6ms	0.53x
>                  desk_forecastio.skp_1	2.01ms ->  999us	0.5x
>                  desk_amazon.skp_1_mpd	1.77ms ->  860us	0.49x
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109

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

Review URL: https://codereview.chromium.org/759753004
 2014-11-25 14:57:26 -08:00
mtklein
7e225bdb1f nanobench: lazily decode bitmaps in .skps. 
This cuts down on tool overhead when running something like recording only,
    $ out/Release/nanobench --match skp --config nonrendering
which doesn't usually ever need to decode the images.

The actual measurements for recording don't change, as the decode is not in the timed section.  It just skips irrelevant code, removing it from the profile and making the tool run faster.

This does, however, make a significant difference for playback speed.  Most skps draw faster with this patch, some slower.  I don't really have a good intuition for what's going on here.  There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded.  Ideas?  Is this perhaps because we're now blitting from smaller, partially decoded source images?

~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log
                   tabl_slashdot.skp_1	2.76ms -> 4.33ms	1.57x
               tabl_slashdot.skp_1_mpd	2.79ms -> 4.07ms	1.46x
                    tabl_sahadan.skp_1	3.41ms -> 4.87ms	1.43x
                 tabl_googleblog.skp_1	1.52ms -> 2.05ms	1.35x
               tabl_techmeme.skp_1_mpd	1.14ms -> 1.51ms	1.32x
               tabl_transformice.skp_1	2.61ms -> 3.43ms	1.31x
                tabl_sahadan.skp_1_mpd	3.54ms -> 4.48ms	1.26x
                   tabl_techmeme.skp_1	1.01ms -> 1.27ms	1.26x
                tabl_nytimes.skp_1_mpd	   1ms -> 1.23ms	1.23x
           tabl_worldjournal.skp_1_mpd	1.98ms -> 2.43ms	1.23x
                 tabl_pravda.skp_1_mpd	2.05ms -> 2.51ms	1.22x
           tabl_transformice.skp_1_mpd	2.75ms -> 3.19ms	1.16x
                    tabl_nytimes.skp_1	 874us -> 1.01ms	1.15x
                     tabl_pravda.skp_1	1.83ms -> 1.99ms	1.09x
               tabl_worldjournal.skp_1	1.76ms -> 1.91ms	1.09x
                desk_wowwiki.skp_1_mpd	 3.7ms ->  3.9ms	1.05x
                       tabl_digg.skp_1	3.99ms -> 4.16ms	1.04x
                  tabl_ukwsj.skp_1_mpd	   3ms -> 3.12ms	1.04x
                    desk_booking.skp_1	3.74ms -> 3.81ms	1.02x
    desk_googlespreadsheetdashed.skp_1	10.6ms -> 10.6ms	1x
                      tabl_ukwsj.skp_1	2.88ms -> 2.89ms	1x
desk_googlespreadsheetdashed.skp_1_mpd	11.8ms -> 11.8ms	1x
     desk_jsfiddlehumperclip.skp_1_mpd	 891us ->  888us	1x
          desk_googlespreadsheet.skp_1	4.65ms -> 4.62ms	0.99x
                  tabl_gspro.skp_1_mpd	1.97ms -> 1.94ms	0.99x
                desk_booking.skp_1_mpd	 4.1ms ->    4ms	0.98x
                     desk_carsvg.skp_1	18.2ms -> 17.7ms	0.97x
            desk_gmailthread.skp_1_mpd	2.81ms -> 2.73ms	0.97x
               desk_tigersvg.skp_1_mpd	19.5ms -> 18.9ms	0.97x
                     desk_mapsvg.skp_1	88.4ms -> 85.6ms	0.97x
                   tabl_cnet.skp_1_mpd	1.43ms -> 1.38ms	0.97x
             desk_jsfiddlebigcar.skp_1	1.26ms -> 1.22ms	0.96x
                        desk_gws.skp_1	1.87ms ->  1.8ms	0.96x
                   desk_linkedin.skp_1	2.07ms -> 1.98ms	0.96x
             tabl_deviantart.skp_1_mpd	 118ms ->  113ms	0.96x
                       tabl_cnet.skp_1	 1.2ms -> 1.14ms	0.95x
          tabl_androidpolice.skp_1_mpd	5.95ms -> 5.63ms	0.95x
                     desk_sfgate.skp_1	1.75ms -> 1.64ms	0.94x
                    desk_twitter.skp_1	  74ms -> 69.6ms	0.94x
                desk_youtube.skp_1_mpd	3.17ms -> 2.96ms	0.93x
                desk_gmailthread.skp_1	2.73ms -> 2.54ms	0.93x
            desk_silkfinance.skp_1_mpd	1.71ms -> 1.59ms	0.93x
         desk_jsfiddlebigcar.skp_1_mpd	1.45ms -> 1.35ms	0.93x
            desk_pokemonwiki.skp_1_mpd	2.72ms -> 2.51ms	0.92x
                    desk_gws.skp_1_mpd	2.14ms -> 1.98ms	0.92x
                 desk_googlehome.skp_1	 563us ->  517us	0.92x
                       desk_espn.skp_1	4.24ms -> 3.89ms	0.92x
          tabl_culturalsolutions.skp_1	12.7ms -> 11.6ms	0.91x
                 desk_sfgate.skp_1_mpd	1.91ms -> 1.74ms	0.91x
                       tabl_hsfi.skp_1	1.06ms ->  966us	0.91x
               desk_samoasvg.skp_1_mpd	10.5ms -> 9.47ms	0.91x
               desk_facebook.skp_1_mpd	 3.8ms -> 3.43ms	0.9x
                    desk_youtube.skp_1	3.52ms -> 3.14ms	0.89x
                   desk_ebay.skp_1_mpd	2.95ms -> 2.62ms	0.89x
                   desk_samoasvg.skp_1	10.9ms -> 9.66ms	0.89x
      desk_googlespreadsheet.skp_1_mpd	5.59ms -> 4.94ms	0.88x
                 desk_mapsvg.skp_1_mpd	 100ms -> 87.9ms	0.88x
                   desk_espn.skp_1_mpd	 4.7ms -> 4.12ms	0.88x
              desk_wordpress.skp_1_mpd	1.92ms -> 1.68ms	0.87x
                 tabl_deviantart.skp_1	 140ms ->  122ms	0.87x
           tabl_cuteoverload.skp_1_mpd	4.41ms -> 3.83ms	0.87x
                   desk_tigersvg.skp_1	19.6ms ->   17ms	0.87x
             tabl_googlecalendar.skp_1	4.01ms -> 3.44ms	0.86x
                    desk_blogger.skp_1	2.49ms -> 2.14ms	0.86x
             desk_chalkboard.skp_1_mpd	52.7ms ->   45ms	0.85x
                    desk_weather.skp_1	2.88ms -> 2.46ms	0.85x
                 desk_chalkboard.skp_1	  51ms -> 43.4ms	0.85x
               desk_yahooanswers.skp_1	2.74ms -> 2.32ms	0.85x
             desk_forecastio.skp_1_mpd	1.26ms -> 1.07ms	0.85x
              tabl_androidpolice.skp_1	5.18ms -> 4.34ms	0.84x
           desk_yahooanswers.skp_1_mpd	3.44ms -> 2.85ms	0.83x
                    tabl_cnn.skp_1_mpd	2.59ms -> 2.15ms	0.83x
                  desk_pinterest.skp_1	2.69ms -> 2.22ms	0.83x
                   tabl_hsfi.skp_1_mpd	 1.6ms -> 1.32ms	0.82x
      tabl_culturalsolutions.skp_1_mpd	13.8ms -> 11.3ms	0.82x
                desk_twitter.skp_1_mpd	76.6ms ->   63ms	0.82x
                       desk_ebay.skp_1	3.11ms -> 2.51ms	0.81x
                    tabl_mlb.skp_1_mpd	3.17ms -> 2.53ms	0.8x
                    tabl_mozilla.skp_1	2.42ms -> 1.91ms	0.79x
                desk_pokemonwiki.skp_1	2.84ms -> 2.22ms	0.78x
                 desk_carsvg.skp_1_mpd	23.3ms -> 17.8ms	0.77x
                    desk_wowwiki.skp_1	4.21ms -> 3.21ms	0.76x
                     desk_amazon.skp_1	 963us ->  728us	0.76x
              desk_css3gradients.skp_1	2.58ms -> 1.92ms	0.74x
               tabl_cuteoverload.skp_1	4.55ms -> 3.38ms	0.74x
                        tabl_cnn.skp_1	3.13ms -> 2.29ms	0.73x
             tabl_googleblog.skp_1_mpd	2.32ms ->  1.7ms	0.73x
                 desk_mobilenews.skp_1	3.65ms -> 2.61ms	0.71x
                 desk_googleplus.skp_1	3.76ms -> 2.66ms	0.71x
                tabl_mozilla.skp_1_mpd	2.88ms -> 2.03ms	0.71x
              desk_pinterest.skp_1_mpd	3.17ms -> 2.21ms	0.7x
          desk_css3gradients.skp_1_mpd	2.98ms -> 2.07ms	0.69x
                desk_silkfinance.skp_1	2.06ms -> 1.42ms	0.69x
                   desk_facebook.skp_1	 4.5ms -> 3.07ms	0.68x
             desk_mobilenews.skp_1_mpd	4.05ms -> 2.73ms	0.68x
                  desk_baidu.skp_1_mpd	2.73ms -> 1.81ms	0.66x
                desk_weather.skp_1_mpd	3.93ms ->  2.5ms	0.64x
                  desk_wordpress.skp_1	2.15ms -> 1.36ms	0.63x
             desk_googlehome.skp_1_mpd	1.02ms ->  605us	0.59x
                   desk_fontwipe.skp_1	 722us ->  402us	0.56x
               desk_fontwipe.skp_1_mpd	 897us ->  486us	0.54x
                      desk_baidu.skp_1	3.02ms ->  1.6ms	0.53x
                 desk_forecastio.skp_1	2.01ms ->  999us	0.5x
                 desk_amazon.skp_1_mpd	1.77ms ->  860us	0.49x

BUG=skia:

Review URL: https://codereview.chromium.org/743613005
 2014-11-25 14:34:03 -08:00
bsalomon
10e23caea3 Use scratch keys for stencil buffers. 
BUG=skia:2889

Committed: https://skia.googlesource.com/skia/+/91175f19664a62851da4ca4e0984a7c7c45b258f

Review URL: https://codereview.chromium.org/747043004
 2014-11-25 05:52:06 -08:00
bsalomon
19cd0f1813 Revert "Use scratch keys for stencil buffers." 
This reverts commit 91175f1966.

Revert "Cleanup res cache bench and split out into a unit test."

This reverts commit 4e4303f002.

Revert "rebaselines"

This reverts commit 65ba7b5775.

TBR=tomhudson@google.com

Review URL: https://codereview.chromium.org/752233002
 2014-11-24 12:19:06 -08:00
reed
90d0ff013b add some debugging to SkNVRefCnt 
BUG=skia:

Review URL: https://codereview.chromium.org/745383003
 2014-11-24 12:02:31 -08:00
bsalomon
4e4303f002 Cleanup res cache bench and split out into a unit test. 
BUG=skia:2889

Review URL: https://codereview.chromium.org/754833002
 2014-11-24 08:25:05 -08:00
bsalomon
91175f1966 Use scratch keys for stencil buffers. 
BUG=skia:2889

Review URL: https://codereview.chromium.org/747043004
 2014-11-24 07:05:15 -08:00
robertphillips
186a08ed72 Fix memory leak in nanobench 
This is cleanup for (Add MultiPictureDraw to nanobench - https://codereview.chromium.org/731973005/)

Review URL: https://codereview.chromium.org/730343003
 2014-11-21 06:53:00 -08:00
robertphillips
5b69377507 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

Review URL: https://codereview.chromium.org/731973005
 2014-11-21 06:19:36 -08:00
robertphillips
e77dadd91a Revert of Add MultiPictureDraw to nanobench (patchset #7 id:120001 of 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
 2014-11-21 05:50:21 -08:00
robertphillips
0ddad31012 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

Review URL: https://codereview.chromium.org/731973005
 2014-11-21 05:35:54 -08:00
robertphillips
8037653195 Add computation of saveLayer information to RecordingBench 
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
 2014-11-18 11:53:02 -08:00
mtklein
a06a953121 Prune SkRTree 
- 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
 2014-11-18 09:27:49 -08:00
kkinnunen
b33402bc87 Do not calculate many sierpinski fractals for each nanobench run unless needed 
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
 2014-11-18 04:50:50 -08:00
bsalomon
12299ab7a1 Make GrResourceCache2 responsible for calling release, abandon, and ~. 
BUG=skia:2889

TBR=robertphillips@google.com

NOTRY=true

Review URL: https://codereview.chromium.org/729683002
 2014-11-14 13:33:09 -08:00
bsalomon
71cb0c241e Replace GrResourceCache with GrResourceCache2. 
BUG=skia:2889

Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6

Committed: https://skia.googlesource.com/skia/+/407aa584d183c1bf314f5defd1cf0202e8a96c89

Review URL: https://codereview.chromium.org/716143004
 2014-11-14 12:10:15 -08:00
bsalomon
ac49acda52 Revert of Replace GrResourceCache with GrResourceCache2. (patchset #7 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
 2014-11-14 06:47:39 -08:00
bsalomon
407aa584d1 Replace GrResourceCache with GrResourceCache2. 
BUG=skia:2889

Committed: https://skia.googlesource.com/skia/+/66a450f21a3da174b7eed89a1d5fc8591e8b6ee6

Review URL: https://codereview.chromium.org/716143004
 2014-11-14 06:29:40 -08:00
bsalomon
f21dab9540 Revert of Replace GrResourceCache with GrResourceCache2. (patchset #6 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
 2014-11-13 13:33:28 -08:00
bsalomon
66a450f21a Replace GrResourceCache with GrResourceCache2. 
BUG=skia:2889

Review URL: https://codereview.chromium.org/716143004
 2014-11-13 13:19:10 -08:00
jcgregorio
3b27adef0a Revert of Make nanobench and dm be usable from Chromium build (patchset #5 id:80001 of https://codereview.chromium.org/657373002/) 
Reason for revert:
Causing breakages on Mac build.

Original issue's description:
> Make nanobench and dm be usable from Chromium build
>
> Move the app logic for each app as follows:
>
> <app>.cpp -- the file which contains main(). Embedders that compile
> their own apps, such as ios shell, upcoming Chromium dm etc, do not use this.
>
> <app>_main.cpp -- the main logic of the Skia test application. This will be
> used by Skia -compiled apps as well as embedder -compiled apps.
>
> <app>_main.h -- the API for the main logic. This will be
> used by Skia -compiled apps as well as embedder -compiled apps.
>
> This way (the upcoming) Chromium dm can setup its Chromium-specific setup
> in custom main(), and then call dm_main(), without the need of any
> SK_BUILD_FOR_XXXX defines controlling whether the tool defines main or not.
>
> BUG=skia:2992
>
> Committed: https://skia.googlesource.com/skia/+/c092d3bdab5f723576cc0346cea3ee282a9cb444

TBR=mtklein@chromium.org,mtklein@google.com,borenet@google.com,kkinnunen@nvidia.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:2992

Review URL: https://codereview.chromium.org/724073002
 2014-11-13 08:06:40 -08:00
kkinnunen
c092d3bdab Make nanobench and dm be usable from Chromium build 
Move the app logic for each app as follows:

<app>.cpp -- the file which contains main(). Embedders that compile
their own apps, such as ios shell, upcoming Chromium dm etc, do not use this.

<app>_main.cpp -- the main logic of the Skia test application. This will be
used by Skia -compiled apps as well as embedder -compiled apps.

<app>_main.h -- the API for the main logic. This will be
used by Skia -compiled apps as well as embedder -compiled apps.

This way (the upcoming) Chromium dm can setup its Chromium-specific setup
in custom main(), and then call dm_main(), without the need of any
SK_BUILD_FOR_XXXX defines controlling whether the tool defines main or not.

BUG=skia:2992

Review URL: https://codereview.chromium.org/657373002
 2014-11-13 05:00:57 -08:00