AuroraMiddleware/skia2
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
16,095 Commits 1 Branch 0 Tags 544 MiB
d160192fd9
Commit Graph

16095 Commits

This Branch
This Branch
All Branches
Author SHA1 Message Date
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
8ed666d230 add gm for stroked circles that are zoomed 
BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/912203002
 2015-02-10 17:44:26 -08:00
reed
8432808ad8 check for inverted rects before we quick-reject 
BUG=skia:

Review URL: https://codereview.chromium.org/908353002
 2015-02-10 14:18:09 -08:00
mtklein
bfd5bff75c Simplify SkBBH::insert API 
No one's exploiting the ability to take ownership of the array anymore.

BUG=skia:

Review URL: https://codereview.chromium.org/913833002
 2015-02-10 13:44:27 -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
halcanary
bf799cd228 Simplify reference management in SkPDF 
Prior to this change, SkPDFObject subclasses were required
to track their resources separately from the document
structure.  (An object has a resource if it depends, via an
indirect reference, on another object).  This led to a lot
of extra code to duplicate effort.  I replace the
getResources() function with the much simpler addResources()
function.  I only define a non-trivial addResources() method
on arrays, dictionaries, and indirect object references.
All other specialized classes simply rely on their parent
class's implementation.

SkPDFObject::addResources() works by recursively walking the
directed graph of object (direct and indirect) references
and adding resources to a set.  It doesn't matter that there
are closed loops in the graph, since we check the set before
walking down a branch.

-  Add SkPDFObject::addResources() virtual function, with
   four implementations
-  Remove SkPDFObject::getResources() virtual function and
   all implementations.
-  Remove SkPDFObject::GetResourcesHelper()
-  Remove SkPDFObject::AddResourceHelper()
-  In SkPDFCatalog::findObjectIndex(), add an object to the
   catalog if it doesn't exist yet.
-  SkPDFCatalog::setSubstitute() no longer sets up resources
-  SkPDFDocument.cpp no longer needs the Streamer object
-  SkPDFDocument.cpp calls fDocCatalog->addResources to build
   the resource list.
-  SkPDFFont::addResource() removed
-  All SkPDF-::fResource sets removed (they are redundant).
-  removed SkPDFImage::addSMask() function
-  SkPDFResourceDict::getReferencedResources() removed.

Motivation: this removes quite a bit of code and makes the
objects slightly slimmer in memory.  Most importantly, this
will lead the way towards removing SkPDFObject's inheritance
from SkRefCnt, which will greatly simplify everything.

Testing: I usually test changes to the PDF backend by
comparing checksums of PDF files rendered from GMs and SKPs
before and after the change.  This change both re-orders and
re-numbers the indirect PDF objects.  I used the qpdf
program to normalize the PDFs and then compared the
normalized outputs from before and after the change; they
matched.

Review URL: https://codereview.chromium.org/870333002
 2015-02-10 13:32:09 -08:00
djsollen
c8262ccbf9 Update docs with instructions for debugging Android SampleApp. 
Review URL: https://codereview.chromium.org/910173002
 2015-02-10 13:17:07 -08:00
mtklein
d9591bb98c Switch font embedding to a compile-time flag, with a todo for runtime. 
BUG=skia:3417

Review URL: https://codereview.chromium.org/910283002
 2015-02-10 11:48:55 -08:00
joshualitt
043e0f60f4 discard when coverage is <= 0 in XP dst copy. 
Darken was 5-20% slower with this CL, though it might improve things a bit to only look at one component of the vector.

BUG=skia:

Review URL: https://codereview.chromium.org/915633002
 2015-02-10 10:06:15 -08:00
henrik.smiding
4e65473069 Add SSE optimization of Color32A_D565 
Adds an SSE4.1 version of the Color32A_D565 function.

Performance improvement in the following benchmarks:
  Xfermode_SrcOver       - ~100%
  luma_colorfilter_large - ~150%
  luma_colorfilter_small - ~60%
  tablebench             - ~10%
  chart_bw               - ~10%
(Measured on a Atom Silvermont core)

Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>

Review URL: https://codereview.chromium.org/892623002
 2015-02-10 09:42:33 -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
reed
454fa71cc3 check for nonfinites in rrects 
BUG=457128

Review URL: https://codereview.chromium.org/913743002
 2015-02-10 08:46:22 -08:00
reed
88f0a99fd4 Use conics for round joins and caps 
patch from issue 909013004 at patchset 20001 (http://crrev.com/909013004#ps20001)

BUG=skia:
TBR=caryclark

Review URL: https://codereview.chromium.org/910213002
 2015-02-10 08:45:06 -08:00
robertphillips
e85a32d4f8 Clean up clipping code a bit 
Review URL: https://codereview.chromium.org/913693002
 2015-02-10 08:16:55 -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
bungeman
eb2be7fa44 Additional cleanups to Android config parsing. 
Properly labels several methods as static.
Use XML_GetBuffer to avoid an extra copy.
Set the memory allocators to Skia's.
Set define in 'defines' instead of cflags.
Update debug dumper.

Review URL: https://codereview.chromium.org/915443002
 2015-02-10 07:51:12 -08:00
mtklein
ee9c49efc9 rewrite ambiguous comment 
It took me a few reads, but it eventually swapped from bunny to duck.

BUG=skia:

Review URL: https://codereview.chromium.org/913733002
 2015-02-10 07:47:31 -08:00
mtklein
1b9c8bb0a1 Only instance-count in SK_DEVELOPER builds (our debug builds, not Chrome's) 
BUG=skia:

Review URL: https://codereview.chromium.org/910973003
 2015-02-10 06:14:05 -08:00
skia.buildbots
ffd008e5ae Update SKP version 
Automatic commit by the RecreateSKPs bot.

TBR=

Review URL: https://codereview.chromium.org/890863004
 2015-02-09 23:04:25 -08:00
mtklein
e72a80db3a Port SkLazyPtr to new SkAtomics.h 
No algorithmic changes.  The new APIs let us avoid a few ugly trips through void*,
and I've made the consume/acquire/release decision explicitly conditioned on TSAN.

This should fix the attached bug, which is TSAN seeing us implementing the
sk_consume_load() with a relaxed load, where we used to pass __ATOMIC_CONSUME
to TSAN.  This restores us to the status quo of a couple weeks ago, where we
use relaxed loads (to avoid an extra dmb on ARM) for all setups except TSAN,
who gets the logically correct memory order, consume.

No public API changes.
TBR=reed@google.com

BUG=chromium:455606

Review URL: https://codereview.chromium.org/908943002
 2015-02-09 14:47:06 -08:00
mtklein
01f797fcb0 SkAtomics: add asserts for valid memory orders. 
Taken from http://en.cppreference.com/w/cpp/atomic/atomic and https://gcc.gnu.org/onlinedocs/gcc/_005f_005fatomic-Builtins.html, which agree.

No public API changes.
TBR=reed@google.com

BUG=skia:

Review URL: https://codereview.chromium.org/868843003
 2015-02-09 14:13:44 -08:00
reed
d5d27d9b14 use conics for arcTo 
guarded by SK_SUPPORT_LEGACY_ARCTO_QUADS

BUG=skia:

Review URL: https://codereview.chromium.org/892703002
 2015-02-09 13:54:43 -08:00
sugoi
8e85761e5a Fixed array read error 
In 32 bits, if the "element count" was under 32 bits, but "element count" * "element size" was over the 32 bit limit, the overflow was causing the read operation to appear as if it had succeded, even though it should have failed.

BUG=456828

Review URL: https://codereview.chromium.org/904833003
 2015-02-09 13:17:21 -08:00
reed
61adb1b649 more gms for conics 
BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/869843006
 2015-02-09 13:01:05 -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
31223e0cb7 cull edges that are to the right of the clip 
BUG=skia:

Review URL: https://codereview.chromium.org/913503002
 2015-02-09 08:33:07 -08:00
reed
70a8ca8351 add rounded-join option to bigpath bench 
BUG=skia:
TBR=
NOTRY=True
... win bot offline

Review URL: https://codereview.chromium.org/909893002
 2015-02-09 08:05:52 -08:00
mtklein
5a2a5e729c Revert of Make the glyph array entries inline. (patchset #11 id:190001 of https://codereview.chromium.org/885903002/) 
Reason for revert:
Still broken.

Original issue's description:
> Make the glyph array entries inline.
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/4c08f16b252a55e438a61f26e5581394ed177da1
>
> Committed: https://skia.googlesource.com/skia/+/b4c29ac173e6f8844327338687248b98bc94132d

TBR=reed@google.com,herb@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/911513003
 2015-02-09 07:52:51 -08:00
egdaniel
41d4f09356 Move GrXferProcessor subclasses into cpp files 
BUG=skia:

Review URL: https://codereview.chromium.org/860383007
 2015-02-09 07:51:00 -08:00
robertphillips
c89f6fb29c Salvage the SampleApp portion of the ill-fated "nudge" CL 
Trying a different approach than nudging but this will still be useful.

Review URL: https://codereview.chromium.org/907453004
 2015-02-09 07:47:17 -08:00
jcgregorio
9396d84945 skoodle1 
Preview: https://skia.org/?cl=864643007

BUG=skia:

Review URL: https://codereview.chromium.org/864643007
 2015-02-09 07:26:56 -08:00
qiankun.miao
e3ecde1205 Remove unnecessary assignment 
BUG=skia:

Review URL: https://codereview.chromium.org/892423005
 2015-02-09 07:08:05 -08:00
herb
b4c29ac173 Make the glyph array entries inline. 
BUG=skia:

Committed: https://skia.googlesource.com/skia/+/4c08f16b252a55e438a61f26e5581394ed177da1

Review URL: https://codereview.chromium.org/885903002
 2015-02-09 06:38:28 -08:00
skia.buildbots
4e534d05b7 Update SKP version 
Automatic commit by the RecreateSKPs bot.

TBR=

Review URL: https://codereview.chromium.org/889693004
 2015-02-08 22:35:14 -08:00
henrik.smiding
e6b1a60758 Remove opaque versions of Color32_D565 
Removes the opaque-only versions of this function from the factory since
they will never be used. Opaque source colors are handled in
SkRGB16_Opaque_Blitter instead, which doesn't use the factory function.

Signed-off-by: Henrik Smiding <henrik.smiding@intel.com>

Review URL: https://codereview.chromium.org/901593002
 2015-02-08 16:03:27 -08:00
Mike Klein
4f66d5b9b1 turns out the newlines matter 
BUG=skia:

Review URL: https://codereview.chromium.org/886913004
 2015-02-08 18:48:55 -05:00
Mike Klein
b486083fc0 one day i will bother to look at the markdown rendering 
BUG=skia:

Review URL: https://codereview.chromium.org/908783002
 2015-02-08 18:36:19 -05:00
halcanary
b8d4635258 documentation: formatting site/dev/contrib/c++11 
TBR=mtklein@chromium.org

NOTRY=true

Review URL: https://codereview.chromium.org/891603003
 2015-02-08 07:09:22 -08:00
skia.buildbots
067f8ab32a Update SKP version 
Automatic commit by the RecreateSKPs bot.

TBR=

Review URL: https://codereview.chromium.org/906033002
 2015-02-07 22:39:11 -08:00
reed
01d3319b67 Faster edge re-sort 
For now, disable dropping trailing edges

This reverts commit 0692c5f2c1.

BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/882733004
 2015-02-07 12:18:41 -08:00
skia.buildbots
5cc0f6c1ac Update SKP version 
Automatic commit by the RecreateSKPs bot.

TBR=

Review URL: https://codereview.chromium.org/898303004
 2015-02-06 23:03:26 -08:00
reed
0692c5f2c1 Revert of Faster edge re-sort, drop trailing edges (patchset #2 id:20001 of https://codereview.chromium.org/907623002/) 
Reason for revert:
still layout failures

Original issue's description:
> Faster edge re-sort, drop trailing edges
>
> (patchset #4 id:60001 of https://codereview.chromium.org/891613003/)"
>
> This reverts commit c319d075ea.
>
> BUG=skia:
> TBR=
>
> Committed: https://skia.googlesource.com/skia/+/2322115952c15c72a623837879cac1f85894b1b6

TBR=
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/886503010
 2015-02-06 21:08:33 -08:00
reed
2322115952 Faster edge re-sort, drop trailing edges 
(patchset #4 id:60001 of https://codereview.chromium.org/891613003/)"

This reverts commit c319d075ea.

BUG=skia:
TBR=

Review URL: https://codereview.chromium.org/907623002
 2015-02-06 19:29:15 -08:00
reed
c319d075ea Revert of faster edge re-sort, drop trailing edges (patchset #4 id:60001 of https://codereview.chromium.org/891613003/) 
Reason for revert:
may be breaking layouttests...

Original issue's description:
> faster edge re-sort, drop trailing edges
>
> 1. drop edges that are wholly on the right (in the non-convex walker)
> 2. scan and swap once, instead of swapping as we go during re-sort
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/38f1c00772539dcbeccbfa3c45d94bdc4acf3518

TBR=caryclark@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Review URL: https://codereview.chromium.org/910493002
 2015-02-06 18:07:39 -08:00
joshualitt
70f00046a4 simple fix to close batches on anything push to the GrIODB recorder 
BUG=skia:

Review URL: https://codereview.chromium.org/865153005
 2015-02-06 15:53:59 -08:00
reed
38f1c00772 faster edge re-sort, drop trailing edges 
1. drop edges that are wholly on the right (in the non-convex walker)
2. scan and swap once, instead of swapping as we go during re-sort

BUG=skia:

Review URL: https://codereview.chromium.org/891613003
 2015-02-06 14:18:46 -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