bsalomon
6bc1b5fab8
Dynamically create stencil buffer when needed.
...
Review URL: https://codereview.chromium.org/938383004
2015-02-23 09:06:38 -08:00
bsalomon
42380174ca
Use D3D11 backend for ANGLE when available.
...
Review URL: https://codereview.chromium.org/954453002
2015-02-23 08:57:23 -08:00
scroggo
953df445ab
Remove SK_SUPPORT_LEGACY_GET_PIXELS_ENUM.
...
SK_SUPPORT_LEGACY_GET_PIXELS_ENUM just set a \#define to convert
onGetPixelsEnum
to
onGetPixels
Now that Chrome has been updated to override onGetPixels, there is no
need for the define.
BUG=skia:3257
Review URL: https://codereview.chromium.org/933853004
2015-02-23 07:07:25 -08:00
reed
0ab326f530
move GMSampleView into its own cpp
...
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/947733002
2015-02-21 09:36:50 -08:00
fmalita
7a048690d3
[SVGDevice] Text whitespace unittest
...
Plumb SkDOM as needed to make it suitable for an SkXMLWriter backend.
Also fix a potential null typeface issue in
SkSVGDevice::AutoElement::addTextAttributes().
R=reed@google.com ,mtklein@google.com
Review URL: https://codereview.chromium.org/940283002
2015-02-20 13:54:40 -08:00
mtklein
2aa1f7e679
Port GrGLCaps over to use SkTHash.
...
I've written some new hashtable interfaces that should be easier to use,
and I've been trying to roll them out bit by bit, hopefully replacing
SkTDynamicHash, SkTMultiMap, SkTHashCache, etc.
This turns the cache in GrGLCaps::readPixelsSupported() into an SkTHashMap,
mapping the format key to a bool. Functionally, it's the same.
BUG=skia:
Review URL: https://codereview.chromium.org/948473002
2015-02-20 12:35:32 -08:00
caryclark
04e4d08556
This uses quad approximations of the outer and inner paths describing a stroke. Cubics and conics' thick strokes are approximated with quads as well.
...
The approximation uses a similar error term as the fill scan converter to determine the number of quads to use.
This also updates SampleApp QuadStroker test with conics, ovals, and stroked text.
Review URL: https://codereview.chromium.org/932113002
2015-02-20 06:33:57 -08:00
halcanary
56f4ace232
PDF: Remove SkPDFDeviceFlattener
...
There are no clients.
TBR=mtklein@google.com
Review URL: https://codereview.chromium.org/937333002
2015-02-19 18:55:05 -08:00
scroggo
87fa631969
Rename onGetPixelsEnum back to onGetPixels.
...
Replace the old signature of onGetPixels (return bool) to return an
enum (Result). Remove onGetPixelsEnum.
Add a define for onGetPixelsEnum to onGetPixels. This is for staging
in Chromium, where some implementations override onGetPixelsEnum.
Add the define in skia_for_chromium_defines. Remove
SK_SUPPORT_LEGACY_IMAGE_GENERATOR_RETURN, which is no longer needed by
Chromium.
BUG=skia:3257
Review URL: https://codereview.chromium.org/939113002
2015-02-19 18:44:58 -08:00
reed
c8e4765b8e
gm to illustrate mipmap layer choice
...
BUG=skia:
NOTREECHECKS=True
TBR=
Review URL: https://codereview.chromium.org/942593002
2015-02-19 11:39:46 -08:00
joshualitt
6364807151
gm to test hairlines which fill RenderTarget
...
BUG=skia:
Review URL: https://codereview.chromium.org/934283002
2015-02-19 10:25:21 -08:00
halcanary
07327bff1b
move SkPDFD*.h from include to src
...
CQ_INCLUDE_TRYBOTS=client.skia:Mac Builder-Trybot,Linux Builder-Trybot,Win Builder-Trybot
Review URL: https://codereview.chromium.org/727343002
2015-02-19 07:26:13 -08:00
jvanverth
5a105ff053
Use uint16s for texture coordinates when rendering text.
...
Allows us to push more vertices into a given vertex buffer, with
a slight performance improvement.
Committed: https://skia.googlesource.com/skia/+/059034d252007d0dd86fff5ffdbb53cbcb10d34b
Review URL: https://codereview.chromium.org/917373002
2015-02-18 11:36:35 -08:00
halcanary
1b5c604d9d
PDF: Add (low-memory) SkPDFBitmap class
...
Also: Add SkDeflateWStream and associated unit tests.
SkPDFBitmap is a replacement for SkPDFImage. As of now, it only
supports 8888 bitmaps (the most common case).
SkPDFBitmap takes very little extra memory (aside from refing the
bitmap's pixels), and its emitObject() does not cache any data.
The SkPDFBitmap::Create function will check the canon for duplicates.
This can reduce the size of the output PDF.
Motivation: this gives another ~40% decrease in PDF memory overhead
TODO: Support other ColorTypes and scrap SkPDFImage.
BUG=skia:3030
Review URL: https://codereview.chromium.org/918813002
2015-02-18 11:29:57 -08:00
caryclark
88c748aeea
update sampleapp for stroking experiment
...
Add RotateCircles3 back as better-named QuadStroker.
Switch pathfill test to call skia before draw instead of in
initializer to avoid triggering debugging breakpoints.
Review URL: https://codereview.chromium.org/912273003
2015-02-18 10:56:00 -08:00
mtklein
4c7a8b04a0
fix xcode build
...
NOTREECHECKS=true
BUG=skia:
Review URL: https://codereview.chromium.org/936033003
2015-02-18 09:35:49 -08:00
reed
e4ef1ca5be
Revert of Use uint16s for texture coordinates when rendering text. (patchset #5 id:80001 of https://codereview.chromium.org/917373002/ )
...
Reason for revert:
speculative revert for DEPS failures
https://codereview.chromium.org/932973002/
Original issue's description:
> Use uint16s for texture coordinates when rendering text.
>
> Allows us to push more vertices into a given vertex buffer, with
> a slight performance improvement.
>
> Committed: https://skia.googlesource.com/skia/+/059034d252007d0dd86fff5ffdbb53cbcb10d34b
TBR=joshualitt@google.com ,robertphillips@google.com,bsalomon@google.com,reed@google.com,djsollen@google.com,jvanverth@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Review URL: https://codereview.chromium.org/920333003
2015-02-17 18:38:38 -08:00
halcanary
91d1d621de
zlib/pdf: remove HaveFlate(), depend on preprocessor defines
...
Review URL: https://codereview.chromium.org/933523007
2015-02-17 14:43:06 -08:00
mtklein
1e4e814c03
SK_NO_FLATE
...
Also remove skia_zlib_static. We're not using it. We don't even have zlib in DEPS.
No public API changes.
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/936583002
2015-02-17 13:10:43 -08:00
jvanverth
059034d252
Use uint16s for texture coordinates when rendering text.
...
Allows us to push more vertices into a given vertex buffer, with
a slight performance improvement.
Review URL: https://codereview.chromium.org/917373002
2015-02-17 08:39:56 -08:00
egdaniel
b197b8ff31
Use SkXfermode as public facing enum for GrPorterDuffXP
...
BUG=skia:
Review URL: https://codereview.chromium.org/926593005
2015-02-17 07:34:43 -08:00
reed
9e447c08de
remove unneeded preroll
...
BUG=skia:
TBR=robertphilips
Review URL: https://codereview.chromium.org/927443006
2015-02-15 11:08:40 -08:00
halcanary
3a6672ae0c
C++11 Unit Test for RValue semantics.
...
Motivation: test that these works on all possible bots and for all possible clients (clients do run these unit tests, right?)
Dear clients: if this unit test fails, let us know!
BUG=skia:3427
Review URL: https://codereview.chromium.org/922043004
2015-02-13 15:12:52 -08:00
bsalomon
3582d3ee9f
Split out methods in GrGpuResource::CacheAccess that can be called outside of the cache.
...
Review URL: https://codereview.chromium.org/923143002
2015-02-13 14:20:05 -08:00
scroggo
0864908ca5
Make SkImageGenerator::getPixels() return an enum.
...
The new enum describes the nature of the failure. This is in
preparation for writing a replacement for SkImageDecoder, which will
use this interface.
Update the comments for getPixels() to specify what it means to pass
an SkImageInfo with a different size.
Make SkImageGenerator Noncopyable.
Leave onGetYUV8Planes alone, since we have separate discussions
regarding modifying that API.
Make callers of SkImageDecoder consistently handle kPartialSuccess.
Previously, some callers considered it a failure, and others considered
it a success.
BUG=skia:3257
Review URL: https://codereview.chromium.org/919693002
2015-02-13 11:13:34 -08:00
bsalomon
3555bd88a6
Add a templated priority queue class.
...
Review URL: https://codereview.chromium.org/914003004
2015-02-13 11:08:21 -08:00
msarett
95f192d199
Adding new benchmark to test image decoding performance.
...
BUG=skia:
Review URL: https://codereview.chromium.org/918673002
2015-02-13 09:05:42 -08:00
fmalita
f89f60f697
[SkSVGDevice] Full font family support
...
Use a family name iterator and list all names instead of just one
returned by SkTypeface::getFamilyName().
R=reed@google.com ,mtklein@google.com
Review URL: https://codereview.chromium.org/923583002
2015-02-13 08:55:24 -08:00
joshualitt
8072caa803
A simple change to move a bunch of stuff out of Gr*Geometry.h
...
BUG=skia:
Review URL: https://codereview.chromium.org/920863002
2015-02-12 14:20:52 -08:00
scroggo
7cd3f64385
Stop adding mssse3 & m32/m64 for Android framework.
...
BUG=skia:3423
Review URL: https://codereview.chromium.org/920703005
2015-02-12 13:27:40 -08:00
mtklein
979e0eacbd
Spin off SkTHashTable, SkTHashMap, SkTHashSet
...
SkTHashTable is very similar to SkTDynamicHash, except it's generalized to support non-pointer value types.
It doesn't support remove(), just to keep things simple (it's not hard to add).
Instead of an iterator, it has foreach(), again, to keep things simple.
SkTHashMap<K,V> and SkTHashSet<T> build a friendlier experience on top of SkTHashTable.
BUG=skia:
Review URL: https://codereview.chromium.org/925613002
2015-02-12 13:20:08 -08:00
scroggo
df1c3373fc
Don't use m32 cflag for x86_64.
...
When checking the skia_arch_type for "x86", instead of doing an
== compare, check if "x86" in skia_arch_type, so it will cover
both x86 and x86_64.
Except when we specifically want x86.
Set skia_arch_width based on "64" in skia_arch_type. No need to specify
in scripts.
In gyp_to_android.py, create a separate var_dict for x86_64.
BUG=skia:3419
Review URL: https://codereview.chromium.org/916113002
2015-02-12 10:48:25 -08:00
joshualitt
95964c670b
GMs now use batch
...
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/3f284d7758d7f35b59d93a22d126f7cd8423be44
Review URL: https://codereview.chromium.org/865313004
2015-02-11 13:45:51 -08:00
joshualitt
94dff15404
Revert of GMs now use batch (patchset #3 id:40001 of https://codereview.chromium.org/865313004/ )
...
Reason for revert:
missing hairlines on gms
Original issue's description:
> GMs now use batch
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/3f284d7758d7f35b59d93a22d126f7cd8423be44
TBR=bsalomon@google.com ,joshualitt@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/913153003
2015-02-11 13:03:16 -08:00
bsalomon
7e34007e1e
Add GrGLCreateNullInterface.cpp back to gyp, and put contents in namespace.
...
TBR=robertphillips@google.com
Review URL: https://codereview.chromium.org/899803004
2015-02-11 12:07:31 -08:00
joshualitt
3f284d7758
GMs now use batch
...
BUG=skia:
Review URL: https://codereview.chromium.org/865313004
2015-02-11 11:34:58 -08:00
bsalomon
bb0502eec5
Support multiple null GL contexts on a thread.
...
This has the side effect of requiring SkNullGLContext to use the null GL interface.
It exposes SkNullGLContext and also removes null context support from SampleApp.
Review URL: https://codereview.chromium.org/916733002
2015-02-11 11:11:11 -08:00
bsalomon
0ea80f43a1
Rename GrResourceCache2->GrResourceCache
...
TBR=robertphillips@google.com
Review URL: https://codereview.chromium.org/921453002
2015-02-11 10:49:59 -08:00
mtklein
d160192fd9
Revert of GYP groudwork for half-float opts support. (patchset #1 id:1 of https://codereview.chromium.org/915693002/ )
...
Reason for revert:
Going to punt on 16-bit float support for now. Can't figure out ARM 64.
Original issue's description:
> GYP groudwork for half-float opts support.
>
> This sets us up two new opts targets with the immediate goal of adding half-float (SkHalf.h) opts:
> - opts_neon_fp16: uses hardware support on most ARM chips with NEON to do 4 conversions at a time;
> - opts_avx: uses hardware support on Intel chips with AVX to do 8 conversions at a time.
>
> opts_avx will be a handy thing to have around later too, especially if we want to work with floats.
>
> This doesn't actually add any new source files to these libraries yet, so they're no-ops for now.
> I'll need to write a parallel change to Chrome's GN and GYPs before we can start adding sources.
>
> This also rolls GYP up to head, to get suppport for EnableEnhancedInstructionSet: '3' on Windows,
> which is how we turn on AVX there. There's no Mac-specific flag, so we use OTHER_CPLUSPLUSFLAGS.
>
> BUG=skia:
>
> TBR=reed@google.com
>
> Committed: https://skia.googlesource.com/skia/+/46b80833394d7919cadf2abf2b93802141dd21c5
TBR=reed@google.com ,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/912223002
2015-02-10 18:18:18 -08:00
mtklein
94aca69d1e
Revert of add dummy avx file so xcode will build (patchset #1 id:1 of https://codereview.chromium.org/916563002/ )
...
Reason for revert:
Going to punt on 16-bit float support for now. Can't figure out ARM 64.
Original issue's description:
> add dummy avx file so xcode will build
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/a0921f2563701d54e4e022de99f2705f4ada8a6e
TBR=reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/912213002
2015-02-10 18:17:17 -08:00
reed
a0921f2563
add dummy avx file so xcode will build
...
BUG=skia:
Review URL: https://codereview.chromium.org/916563002
2015-02-10 13:39:15 -08:00
mtklein
46b8083339
GYP groudwork for half-float opts support.
...
This sets us up two new opts targets with the immediate goal of adding half-float (SkHalf.h) opts:
- opts_neon_fp16: uses hardware support on most ARM chips with NEON to do 4 conversions at a time;
- opts_avx: uses hardware support on Intel chips with AVX to do 8 conversions at a time.
opts_avx will be a handy thing to have around later too, especially if we want to work with floats.
This doesn't actually add any new source files to these libraries yet, so they're no-ops for now.
I'll need to write a parallel change to Chrome's GN and GYPs before we can start adding sources.
This also rolls GYP up to head, to get suppport for EnableEnhancedInstructionSet: '3' on Windows,
which is how we turn on AVX there. There's no Mac-specific flag, so we use OTHER_CPLUSPLUSFLAGS.
BUG=skia:
TBR=reed@google.com
Review URL: https://codereview.chromium.org/915693002
2015-02-10 09:17:05 -08:00
scroggo
ac928f27ab
Only define SK_CRASH_HANDLER in crash_handler.
...
The macro is only used in CrashHandler.*
Removes SK_CRASH_HANDLER from Android's SkUserConfig, where it is not
needed.
Review URL: https://codereview.chromium.org/915663002
2015-02-10 08:13:26 -08:00
mtklein
57f27bdcbd
Revert of nanobench: lazily decode bitmaps in .skps. (patchset #1 id:1 of https://codereview.chromium.org/743613005/ )
...
Reason for revert:
Well, it still crashes.
Original issue's description:
> nanobench: lazily decode bitmaps in .skps.
>
> This cuts down on tool overhead when running something like recording only,
> $ out/Release/nanobench --match skp --config nonrendering
> which doesn't usually ever need to decode the images.
>
> The actual measurements for recording don't change, as the decode is not in the timed section. It just skips irrelevant code, removing it from the profile and making the tool run faster.
>
> This does, however, make a significant difference for playback speed. Most skps draw faster with this patch, some slower. I don't really have a good intuition for what's going on here. There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded. Ideas? Is this perhaps because we're now blitting from smaller, partially decoded source images?
>
> ~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log
> tabl_slashdot.skp_1 2.76ms -> 4.33ms 1.57x
> tabl_slashdot.skp_1_mpd 2.79ms -> 4.07ms 1.46x
> tabl_sahadan.skp_1 3.41ms -> 4.87ms 1.43x
> tabl_googleblog.skp_1 1.52ms -> 2.05ms 1.35x
> tabl_techmeme.skp_1_mpd 1.14ms -> 1.51ms 1.32x
> tabl_transformice.skp_1 2.61ms -> 3.43ms 1.31x
> tabl_sahadan.skp_1_mpd 3.54ms -> 4.48ms 1.26x
> tabl_techmeme.skp_1 1.01ms -> 1.27ms 1.26x
> tabl_nytimes.skp_1_mpd 1ms -> 1.23ms 1.23x
> tabl_worldjournal.skp_1_mpd 1.98ms -> 2.43ms 1.23x
> tabl_pravda.skp_1_mpd 2.05ms -> 2.51ms 1.22x
> tabl_transformice.skp_1_mpd 2.75ms -> 3.19ms 1.16x
> tabl_nytimes.skp_1 874us -> 1.01ms 1.15x
> tabl_pravda.skp_1 1.83ms -> 1.99ms 1.09x
> tabl_worldjournal.skp_1 1.76ms -> 1.91ms 1.09x
> desk_wowwiki.skp_1_mpd 3.7ms -> 3.9ms 1.05x
> tabl_digg.skp_1 3.99ms -> 4.16ms 1.04x
> tabl_ukwsj.skp_1_mpd 3ms -> 3.12ms 1.04x
> desk_booking.skp_1 3.74ms -> 3.81ms 1.02x
> desk_googlespreadsheetdashed.skp_1 10.6ms -> 10.6ms 1x
> tabl_ukwsj.skp_1 2.88ms -> 2.89ms 1x
> desk_googlespreadsheetdashed.skp_1_mpd 11.8ms -> 11.8ms 1x
> desk_jsfiddlehumperclip.skp_1_mpd 891us -> 888us 1x
> desk_googlespreadsheet.skp_1 4.65ms -> 4.62ms 0.99x
> tabl_gspro.skp_1_mpd 1.97ms -> 1.94ms 0.99x
> desk_booking.skp_1_mpd 4.1ms -> 4ms 0.98x
> desk_carsvg.skp_1 18.2ms -> 17.7ms 0.97x
> desk_gmailthread.skp_1_mpd 2.81ms -> 2.73ms 0.97x
> desk_tigersvg.skp_1_mpd 19.5ms -> 18.9ms 0.97x
> desk_mapsvg.skp_1 88.4ms -> 85.6ms 0.97x
> tabl_cnet.skp_1_mpd 1.43ms -> 1.38ms 0.97x
> desk_jsfiddlebigcar.skp_1 1.26ms -> 1.22ms 0.96x
> desk_gws.skp_1 1.87ms -> 1.8ms 0.96x
> desk_linkedin.skp_1 2.07ms -> 1.98ms 0.96x
> tabl_deviantart.skp_1_mpd 118ms -> 113ms 0.96x
> tabl_cnet.skp_1 1.2ms -> 1.14ms 0.95x
> tabl_androidpolice.skp_1_mpd 5.95ms -> 5.63ms 0.95x
> desk_sfgate.skp_1 1.75ms -> 1.64ms 0.94x
> desk_twitter.skp_1 74ms -> 69.6ms 0.94x
> desk_youtube.skp_1_mpd 3.17ms -> 2.96ms 0.93x
> desk_gmailthread.skp_1 2.73ms -> 2.54ms 0.93x
> desk_silkfinance.skp_1_mpd 1.71ms -> 1.59ms 0.93x
> desk_jsfiddlebigcar.skp_1_mpd 1.45ms -> 1.35ms 0.93x
> desk_pokemonwiki.skp_1_mpd 2.72ms -> 2.51ms 0.92x
> desk_gws.skp_1_mpd 2.14ms -> 1.98ms 0.92x
> desk_googlehome.skp_1 563us -> 517us 0.92x
> desk_espn.skp_1 4.24ms -> 3.89ms 0.92x
> tabl_culturalsolutions.skp_1 12.7ms -> 11.6ms 0.91x
> desk_sfgate.skp_1_mpd 1.91ms -> 1.74ms 0.91x
> tabl_hsfi.skp_1 1.06ms -> 966us 0.91x
> desk_samoasvg.skp_1_mpd 10.5ms -> 9.47ms 0.91x
> desk_facebook.skp_1_mpd 3.8ms -> 3.43ms 0.9x
> desk_youtube.skp_1 3.52ms -> 3.14ms 0.89x
> desk_ebay.skp_1_mpd 2.95ms -> 2.62ms 0.89x
> desk_samoasvg.skp_1 10.9ms -> 9.66ms 0.89x
> desk_googlespreadsheet.skp_1_mpd 5.59ms -> 4.94ms 0.88x
> desk_mapsvg.skp_1_mpd 100ms -> 87.9ms 0.88x
> desk_espn.skp_1_mpd 4.7ms -> 4.12ms 0.88x
> desk_wordpress.skp_1_mpd 1.92ms -> 1.68ms 0.87x
> tabl_deviantart.skp_1 140ms -> 122ms 0.87x
> tabl_cuteoverload.skp_1_mpd 4.41ms -> 3.83ms 0.87x
> desk_tigersvg.skp_1 19.6ms -> 17ms 0.87x
> tabl_googlecalendar.skp_1 4.01ms -> 3.44ms 0.86x
> desk_blogger.skp_1 2.49ms -> 2.14ms 0.86x
> desk_chalkboard.skp_1_mpd 52.7ms -> 45ms 0.85x
> desk_weather.skp_1 2.88ms -> 2.46ms 0.85x
> desk_chalkboard.skp_1 51ms -> 43.4ms 0.85x
> desk_yahooanswers.skp_1 2.74ms -> 2.32ms 0.85x
> desk_forecastio.skp_1_mpd 1.26ms -> 1.07ms 0.85x
> tabl_androidpolice.skp_1 5.18ms -> 4.34ms 0.84x
> desk_yahooanswers.skp_1_mpd 3.44ms -> 2.85ms 0.83x
> tabl_cnn.skp_1_mpd 2.59ms -> 2.15ms 0.83x
> desk_pinterest.skp_1 2.69ms -> 2.22ms 0.83x
> tabl_hsfi.skp_1_mpd 1.6ms -> 1.32ms 0.82x
> tabl_culturalsolutions.skp_1_mpd 13.8ms -> 11.3ms 0.82x
> desk_twitter.skp_1_mpd 76.6ms -> 63ms 0.82x
> desk_ebay.skp_1 3.11ms -> 2.51ms 0.81x
> tabl_mlb.skp_1_mpd 3.17ms -> 2.53ms 0.8x
> tabl_mozilla.skp_1 2.42ms -> 1.91ms 0.79x
> desk_pokemonwiki.skp_1 2.84ms -> 2.22ms 0.78x
> desk_carsvg.skp_1_mpd 23.3ms -> 17.8ms 0.77x
> desk_wowwiki.skp_1 4.21ms -> 3.21ms 0.76x
> desk_amazon.skp_1 963us -> 728us 0.76x
> desk_css3gradients.skp_1 2.58ms -> 1.92ms 0.74x
> tabl_cuteoverload.skp_1 4.55ms -> 3.38ms 0.74x
> tabl_cnn.skp_1 3.13ms -> 2.29ms 0.73x
> tabl_googleblog.skp_1_mpd 2.32ms -> 1.7ms 0.73x
> desk_mobilenews.skp_1 3.65ms -> 2.61ms 0.71x
> desk_googleplus.skp_1 3.76ms -> 2.66ms 0.71x
> tabl_mozilla.skp_1_mpd 2.88ms -> 2.03ms 0.71x
> desk_pinterest.skp_1_mpd 3.17ms -> 2.21ms 0.7x
> desk_css3gradients.skp_1_mpd 2.98ms -> 2.07ms 0.69x
> desk_silkfinance.skp_1 2.06ms -> 1.42ms 0.69x
> desk_facebook.skp_1 4.5ms -> 3.07ms 0.68x
> desk_mobilenews.skp_1_mpd 4.05ms -> 2.73ms 0.68x
> desk_baidu.skp_1_mpd 2.73ms -> 1.81ms 0.66x
> desk_weather.skp_1_mpd 3.93ms -> 2.5ms 0.64x
> desk_wordpress.skp_1 2.15ms -> 1.36ms 0.63x
> desk_googlehome.skp_1_mpd 1.02ms -> 605us 0.59x
> desk_fontwipe.skp_1 722us -> 402us 0.56x
> desk_fontwipe.skp_1_mpd 897us -> 486us 0.54x
> desk_baidu.skp_1 3.02ms -> 1.6ms 0.53x
> desk_forecastio.skp_1 2.01ms -> 999us 0.5x
> desk_amazon.skp_1_mpd 1.77ms -> 860us 0.49x
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109
>
> Committed: https://skia.googlesource.com/skia/+/1b6b626f9bc0deebe4fe2e63f422d6b122419205
TBR=reed@google.com ,robertphillips@google.com,scroggo@google.com,mtklein@chromium.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/902783005
2015-02-09 11:58:41 -08:00
mtklein
1b6b626f9b
nanobench: lazily decode bitmaps in .skps.
...
This cuts down on tool overhead when running something like recording only,
$ out/Release/nanobench --match skp --config nonrendering
which doesn't usually ever need to decode the images.
The actual measurements for recording don't change, as the decode is not in the timed section. It just skips irrelevant code, removing it from the profile and making the tool run faster.
This does, however, make a significant difference for playback speed. Most skps draw faster with this patch, some slower. I don't really have a good intuition for what's going on here. There is a fixed clip acting as a viewport, so there are probably lots of images that don't ever need to be decoded. Ideas? Is this perhaps because we're now blitting from smaller, partially decoded source images?
~/skia (clean) $ compare clean.log lazy-decode-bitmaps.log
tabl_slashdot.skp_1 2.76ms -> 4.33ms 1.57x
tabl_slashdot.skp_1_mpd 2.79ms -> 4.07ms 1.46x
tabl_sahadan.skp_1 3.41ms -> 4.87ms 1.43x
tabl_googleblog.skp_1 1.52ms -> 2.05ms 1.35x
tabl_techmeme.skp_1_mpd 1.14ms -> 1.51ms 1.32x
tabl_transformice.skp_1 2.61ms -> 3.43ms 1.31x
tabl_sahadan.skp_1_mpd 3.54ms -> 4.48ms 1.26x
tabl_techmeme.skp_1 1.01ms -> 1.27ms 1.26x
tabl_nytimes.skp_1_mpd 1ms -> 1.23ms 1.23x
tabl_worldjournal.skp_1_mpd 1.98ms -> 2.43ms 1.23x
tabl_pravda.skp_1_mpd 2.05ms -> 2.51ms 1.22x
tabl_transformice.skp_1_mpd 2.75ms -> 3.19ms 1.16x
tabl_nytimes.skp_1 874us -> 1.01ms 1.15x
tabl_pravda.skp_1 1.83ms -> 1.99ms 1.09x
tabl_worldjournal.skp_1 1.76ms -> 1.91ms 1.09x
desk_wowwiki.skp_1_mpd 3.7ms -> 3.9ms 1.05x
tabl_digg.skp_1 3.99ms -> 4.16ms 1.04x
tabl_ukwsj.skp_1_mpd 3ms -> 3.12ms 1.04x
desk_booking.skp_1 3.74ms -> 3.81ms 1.02x
desk_googlespreadsheetdashed.skp_1 10.6ms -> 10.6ms 1x
tabl_ukwsj.skp_1 2.88ms -> 2.89ms 1x
desk_googlespreadsheetdashed.skp_1_mpd 11.8ms -> 11.8ms 1x
desk_jsfiddlehumperclip.skp_1_mpd 891us -> 888us 1x
desk_googlespreadsheet.skp_1 4.65ms -> 4.62ms 0.99x
tabl_gspro.skp_1_mpd 1.97ms -> 1.94ms 0.99x
desk_booking.skp_1_mpd 4.1ms -> 4ms 0.98x
desk_carsvg.skp_1 18.2ms -> 17.7ms 0.97x
desk_gmailthread.skp_1_mpd 2.81ms -> 2.73ms 0.97x
desk_tigersvg.skp_1_mpd 19.5ms -> 18.9ms 0.97x
desk_mapsvg.skp_1 88.4ms -> 85.6ms 0.97x
tabl_cnet.skp_1_mpd 1.43ms -> 1.38ms 0.97x
desk_jsfiddlebigcar.skp_1 1.26ms -> 1.22ms 0.96x
desk_gws.skp_1 1.87ms -> 1.8ms 0.96x
desk_linkedin.skp_1 2.07ms -> 1.98ms 0.96x
tabl_deviantart.skp_1_mpd 118ms -> 113ms 0.96x
tabl_cnet.skp_1 1.2ms -> 1.14ms 0.95x
tabl_androidpolice.skp_1_mpd 5.95ms -> 5.63ms 0.95x
desk_sfgate.skp_1 1.75ms -> 1.64ms 0.94x
desk_twitter.skp_1 74ms -> 69.6ms 0.94x
desk_youtube.skp_1_mpd 3.17ms -> 2.96ms 0.93x
desk_gmailthread.skp_1 2.73ms -> 2.54ms 0.93x
desk_silkfinance.skp_1_mpd 1.71ms -> 1.59ms 0.93x
desk_jsfiddlebigcar.skp_1_mpd 1.45ms -> 1.35ms 0.93x
desk_pokemonwiki.skp_1_mpd 2.72ms -> 2.51ms 0.92x
desk_gws.skp_1_mpd 2.14ms -> 1.98ms 0.92x
desk_googlehome.skp_1 563us -> 517us 0.92x
desk_espn.skp_1 4.24ms -> 3.89ms 0.92x
tabl_culturalsolutions.skp_1 12.7ms -> 11.6ms 0.91x
desk_sfgate.skp_1_mpd 1.91ms -> 1.74ms 0.91x
tabl_hsfi.skp_1 1.06ms -> 966us 0.91x
desk_samoasvg.skp_1_mpd 10.5ms -> 9.47ms 0.91x
desk_facebook.skp_1_mpd 3.8ms -> 3.43ms 0.9x
desk_youtube.skp_1 3.52ms -> 3.14ms 0.89x
desk_ebay.skp_1_mpd 2.95ms -> 2.62ms 0.89x
desk_samoasvg.skp_1 10.9ms -> 9.66ms 0.89x
desk_googlespreadsheet.skp_1_mpd 5.59ms -> 4.94ms 0.88x
desk_mapsvg.skp_1_mpd 100ms -> 87.9ms 0.88x
desk_espn.skp_1_mpd 4.7ms -> 4.12ms 0.88x
desk_wordpress.skp_1_mpd 1.92ms -> 1.68ms 0.87x
tabl_deviantart.skp_1 140ms -> 122ms 0.87x
tabl_cuteoverload.skp_1_mpd 4.41ms -> 3.83ms 0.87x
desk_tigersvg.skp_1 19.6ms -> 17ms 0.87x
tabl_googlecalendar.skp_1 4.01ms -> 3.44ms 0.86x
desk_blogger.skp_1 2.49ms -> 2.14ms 0.86x
desk_chalkboard.skp_1_mpd 52.7ms -> 45ms 0.85x
desk_weather.skp_1 2.88ms -> 2.46ms 0.85x
desk_chalkboard.skp_1 51ms -> 43.4ms 0.85x
desk_yahooanswers.skp_1 2.74ms -> 2.32ms 0.85x
desk_forecastio.skp_1_mpd 1.26ms -> 1.07ms 0.85x
tabl_androidpolice.skp_1 5.18ms -> 4.34ms 0.84x
desk_yahooanswers.skp_1_mpd 3.44ms -> 2.85ms 0.83x
tabl_cnn.skp_1_mpd 2.59ms -> 2.15ms 0.83x
desk_pinterest.skp_1 2.69ms -> 2.22ms 0.83x
tabl_hsfi.skp_1_mpd 1.6ms -> 1.32ms 0.82x
tabl_culturalsolutions.skp_1_mpd 13.8ms -> 11.3ms 0.82x
desk_twitter.skp_1_mpd 76.6ms -> 63ms 0.82x
desk_ebay.skp_1 3.11ms -> 2.51ms 0.81x
tabl_mlb.skp_1_mpd 3.17ms -> 2.53ms 0.8x
tabl_mozilla.skp_1 2.42ms -> 1.91ms 0.79x
desk_pokemonwiki.skp_1 2.84ms -> 2.22ms 0.78x
desk_carsvg.skp_1_mpd 23.3ms -> 17.8ms 0.77x
desk_wowwiki.skp_1 4.21ms -> 3.21ms 0.76x
desk_amazon.skp_1 963us -> 728us 0.76x
desk_css3gradients.skp_1 2.58ms -> 1.92ms 0.74x
tabl_cuteoverload.skp_1 4.55ms -> 3.38ms 0.74x
tabl_cnn.skp_1 3.13ms -> 2.29ms 0.73x
tabl_googleblog.skp_1_mpd 2.32ms -> 1.7ms 0.73x
desk_mobilenews.skp_1 3.65ms -> 2.61ms 0.71x
desk_googleplus.skp_1 3.76ms -> 2.66ms 0.71x
tabl_mozilla.skp_1_mpd 2.88ms -> 2.03ms 0.71x
desk_pinterest.skp_1_mpd 3.17ms -> 2.21ms 0.7x
desk_css3gradients.skp_1_mpd 2.98ms -> 2.07ms 0.69x
desk_silkfinance.skp_1 2.06ms -> 1.42ms 0.69x
desk_facebook.skp_1 4.5ms -> 3.07ms 0.68x
desk_mobilenews.skp_1_mpd 4.05ms -> 2.73ms 0.68x
desk_baidu.skp_1_mpd 2.73ms -> 1.81ms 0.66x
desk_weather.skp_1_mpd 3.93ms -> 2.5ms 0.64x
desk_wordpress.skp_1 2.15ms -> 1.36ms 0.63x
desk_googlehome.skp_1_mpd 1.02ms -> 605us 0.59x
desk_fontwipe.skp_1 722us -> 402us 0.56x
desk_fontwipe.skp_1_mpd 897us -> 486us 0.54x
desk_baidu.skp_1 3.02ms -> 1.6ms 0.53x
desk_forecastio.skp_1 2.01ms -> 999us 0.5x
desk_amazon.skp_1_mpd 1.77ms -> 860us 0.49x
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/7e225bdb1f00ae4aed524ff8d0a61df3d3abb109
Review URL: https://codereview.chromium.org/743613005
2015-02-09 11:44:23 -08:00
reed
37a4736971
add bench for very big paths
...
BUG= 455429
TBR=
Review URL: https://codereview.chromium.org/909563002
2015-02-06 13:04:16 -08:00
fmalita
2aafe6f427
Add SkSVGCanvas
...
Add a public SVG canvas factory + move the SVG files from
experimental -> src/svg/.
Update current clients to the new API.
R=reed@google.com , mtklein@google.com , halcanary@google.com
Review URL: https://codereview.chromium.org/902583006
2015-02-06 12:51:10 -08:00
fmalita
02c8fd0ad5
Move SVG parser files under {include,src}/svg/parser/
...
R=reed@google.com
Review URL: https://codereview.chromium.org/884713007
2015-02-06 08:43:51 -08:00
reed
3cb3840c9a
Rename SkCanvasDrawable to SkDrawable, and make public
...
(patchset #2 id:20001 of https://codereview.chromium.org/903993002/ )"
This reverts commit c4e8772492
.
BUG=skia:
TBR=
NOTREECHECKS=True
Review URL: https://codereview.chromium.org/898343004
2015-02-06 08:36:15 -08:00
reed
c4e8772492
Revert of rename SkCanvasDrawable to SkDrawable, and make public (patchset #2 id:20001 of https://codereview.chromium.org/903993002/ )
...
Reason for revert:
bug in gyp
Original issue's description:
> rename SkCanvasDrawable to SkDrawable, and make public
>
> BUG=skia:
> NOTRY=True
> ... winbuilder flake
>
> Committed: https://skia.googlesource.com/skia/+/4ae9eb7463cf2160723407359608f221c0d5e2a6
TBR=robertphillips@google.com ,djsollen@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/882853006
2015-02-06 08:20:07 -08:00