| Commit message (Collapse) | Author | Age |
... | |
|
|
|
|
|
|
|
|
| |
Eventually I'll want to merge them into this file, but not just yet.
NOTRY=true
BUG=skia:4132
Review URL: https://codereview.chromium.org/1257933003
|
|
|
|
|
|
|
| |
NOTRY=true
BUG=skia:4132
Review URL: https://codereview.chromium.org/1269543002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C.f. https://codereview.chromium.org/1261013003/
BUG=skia:4126
Will follow up with two more CLs if this works:
- one moving SkRecords.h
- one moving SkMiniRecorder.h
No public API changes.
TBR=reed@google.com
Committed: https://skia.googlesource.com/skia/+/117842223bd13325b6da26110d80e0590c1a742b
Review URL: https://codereview.chromium.org/1266593002
|
|
|
|
|
|
| |
BUG=510931
Review URL: https://codereview.chromium.org/1256763005
|
|
|
|
|
|
| |
BUG=skia:4135
Review URL: https://codereview.chromium.org/1267543002
|
|
|
|
|
|
|
| |
TBR=reed@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1260473004
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 117842223bd13325b6da26110d80e0590c1a742b.
No good:
https://uberchromegw.corp.google.com/i/client.skia/builders/Mac%20Builder/builds/3465/steps/compile/logs/stdio
BUG=skia:4126
Review URL: https://codereview.chromium.org/1262173002 .
|
|
|
|
|
|
|
| |
BUG=skia:
TBR=
Review URL: https://codereview.chromium.org/1262143002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
C.f. https://codereview.chromium.org/1261013003/
BUG=skia:4126
Will follow up with two more CLs if this works:
- one moving SkRecords.h
- one moving SkMiniRecorder.h
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1266593002
|
|
|
|
|
|
|
|
| |
BUG=skia:
NOTRY=true
DOCS_PREVIEW= https://skia.org/dev/contrib/c++11?cl=1263793002
Review URL: https://codereview.chromium.org/1263793002
|
|
|
|
|
|
|
|
|
|
|
| |
Works like dm_flags.py and nanobench_flags.py; adds things like
GYP_DEFINES, additional environment variables, and build targets.
Required copying builder_name_schema from the tools/build repo.
BUG=skia:4132
Review URL: https://codereview.chromium.org/1265623002
|
|
|
|
|
|
| |
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1259093004
|
|
|
|
|
|
| |
TBR=joshualitt@google.com
Review URL: https://codereview.chromium.org/1259103004
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This breaks Sinks down into three auto-detected types:
- GPU: anything that requests to be run in the GPU enclave
- Vector: anything that writes to the stream instead of the bitmap
- Raster: everything else
Some examples: gpu -> GPU, msaa16 -> GPU, 8888 -> raster, pdf -> vector,
svg -> vector, pipe-8888 -> raster, tiles_rt-gpu -> GPU
This lets image decoding sinks veto non-raster backends explicitly,
and can let particular GMs veto GPU or non-GPU sinks as they like.
BUG=skia:
Review URL: https://codereview.chromium.org/1239953004
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1261033005
|
|
|
|
|
|
| |
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1262703002
|
|
|
|
|
|
|
|
| |
BUG=chromium:514716
TBR=robertphillips@google.com
Review URL: https://codereview.chromium.org/1258673009
|
|
|
|
|
|
|
|
| |
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/0341b4427e5f037e3b501ed6e57dfdb7b40f150e
Review URL: https://codereview.chromium.org/1257073003
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit d12e6ffa5cc1c1af47bf73c7c127d8d7f7443058.
Our Chrome roll canaries are failing with the dreaded
Ninja-says-there's-more-work-to-do message. I will break this up
smaller (if possible) and try again tomorrow.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1258293004 .
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/1257073003/)
Reason for revert:
breaking write pixels test on bots
Original issue's description:
> Move draw on upload decision in GrGpu
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/0341b4427e5f037e3b501ed6e57dfdb7b40f150e
TBR=robertphillips@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1260293004
|
|
|
|
|
|
| |
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1263593004
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ git grep "../../src/" | grep include
now returns nothing.
BUG=skia:4126
No public API changes.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1261013003
|
|
|
|
|
|
|
| |
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1259303003
|
|
|
|
|
|
| |
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1261093002
|
|
|
|
|
|
| |
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1263553002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1257333002
|
|
|
|
|
|
|
| |
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1257193002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1261033002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
include/views/SkOSWindow_Win.h includes it.
To move SkTHash.h to include/private, SkChecksum.h needs to go there too. To move SkChecksum.h to include/private, SkTLogic needs to go there too.
This adds a bunch of -Iinclude/private to tools.gyp I missed in the last CL.
No public API changes.
TBR=reed@google.com
BUG=skia:4126
Review URL: https://codereview.chromium.org/1260613006
|
|
|
|
|
|
|
|
| |
TBR=
BUG=skia:
Review URL: https://codereview.chromium.org/1261043002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1257073003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I'll be moving headers from src/core to include/private, so this guarantees
that anyone who was finding them via -Isrc/core can now find them via
-Iinclude/private.
This is purely mechanical, mostly to preserve my sanity, so it's likely
(harmless) overkill.
Chromium's GYP and GN builds already set -Iinclude/private for Skia builds.
BUG=skia:4126
Review URL: https://codereview.chromium.org/1265443002
|
|
|
|
|
|
| |
BUG=skia:4126
Review URL: https://codereview.chromium.org/1259953004
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1239193002
|
|
|
|
|
|
|
|
|
|
| |
This is a contract change for SkPath::getBounds(), which formally was defined to return 0,0,0,0 for a 1-point path, regardless of the coordinates of that point. This seems wacky/inconsistent, and was causing other bugs (incorrect bounds) when this was unioned with other rects.
Does anyone remember why we defined it this way?
BUG=513799
Review URL: https://codereview.chromium.org/1261773002
|
|
|
|
|
|
|
|
| |
NOTRY=true
TBR=djsollen
BUG=skia:
Review URL: https://codereview.chromium.org/1258253002
|
|
|
|
|
|
|
| |
NOTRY=true
BUG=skia:
Review URL: https://codereview.chromium.org/1261873002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The divide by w can generate slightly erroneous results even
for t == 0 or t == 1. The error in turn defeats detecting
a point in common for a pair of curves that travel in
opposite directions.
Instead, special case endpoints when the t is 0 or 1.
TBR=reed@google.com
BUG=514118
Review URL: https://codereview.chromium.org/1259513004
|
|
|
|
|
|
|
|
|
|
|
| |
Per our discussion, we can make the swizzler simpler and more usable
for SkCodec and SkScanlineDecoder by only having a single version of
next() which takes a pointer to the srcRow and a pointer to the
dstRow.
BUG=skia:
Review URL: https://codereview.chromium.org/1256373002
|
|
|
|
|
|
|
| |
NOTRY=true
DOCS_PREVIEW= https://skia.org/user/api/skpaint?cl=1240893003
Review URL: https://codereview.chromium.org/1240893003
|
|
|
|
|
|
|
|
| |
Follow-up to https://codereview.chromium.org/1228083004
BUG=skia:
Review URL: https://codereview.chromium.org/1256853004
|
|
|
|
|
|
| |
BUG=514143
Review URL: https://codereview.chromium.org/1252973003
|
|
|
|
|
|
|
| |
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1253393002
|
|
|
|
|
|
| |
BUG=skia:
Review URL: https://codereview.chromium.org/1253493002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
https://codereview.chromium.org/1255193002/)
Reason for revert:
Chromium doesn't call SkGraphics::Init(). This setup won't work.
Original issue's description:
> Lay groundwork for SkOpts.
>
> This doesn't really do anything yet. It's just the CPU detection code, skeleton new .cpp files, and a few little .gyp tweaks.
>
> BUG=skia:4117
>
> Committed: https://skia.googlesource.com/skia/+/ce2c5055cee5d5d3c9fc84c1b3eeed4b4d84a827
TBR=djsollen@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:4117
Review URL: https://codereview.chromium.org/1261743002
|
|
|
|
|
|
|
| |
TBR=bsalomon@google.com
BUG=skia:
Review URL: https://codereview.chromium.org/1260023003
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's only implemented on x86, where the exisiting benchmark says memcpy() is
faster for all cases:
Timer overhead: 24ns
curr/maxrss loops min median mean max stddev samples config bench
10/10 MB 1 35.9µs 36.2µs 36.2µs 36.6µs 1% ▁▂▄▅▅▃█▄▄▅ nonrendering sk_memcpy32_100000
10/10 MB 13 2.27µs 2.28µs 2.28µs 2.29µs 0% █▄▃▅▃▁▃▅▁▄ nonrendering sk_memcpy32_10000
11/11 MB 677 91.6ns 95.9ns 94.5ns 99.4ns 3% ▅▅▅▅▅█▁▁▁▁ nonrendering sk_memcpy32_1000
11/11 MB 1171 20ns 20.9ns 21.3ns 23.4ns 6% ▁▁▇▃▃▃█▇▃▃ nonrendering sk_memcpy32_100
11/11 MB 1952 14ns 14ns 14.3ns 15.2ns 3% ▁▁██▁▁▁▁▁▁ nonrendering sk_memcpy32_10
11/11 MB 5 33.6µs 33.7µs 34.1µs 35.2µs 2% ▆▇█▁▁▁▁▁▁▁ nonrendering memcpy32_memcpy_100000
11/11 MB 18 2.12µs 2.22µs 2.24µs 2.39µs 5% ▂█▄▇█▄▇▁▁▁ nonrendering memcpy32_memcpy_10000
11/11 MB 1112 87.3ns 87.3ns 89.1ns 93.7ns 3% ▄██▄▁▁▁▁▁▁ nonrendering memcpy32_memcpy_1000
11/11 MB 2124 12.8ns 13.3ns 13.5ns 14.8ns 6% ▁▁▁█▃▃█▇▃▃ nonrendering memcpy32_memcpy_100
11/11 MB 3077 9ns 9.41ns 9.52ns 10.2ns 4% ▃█▁█▃▃▃▃▃▃ nonrendering memcpy32_memcpy_10
(Why? One fewer thing to port to SkOpts.)
BUG=skia:4117
Review URL: https://codereview.chromium.org/1256763003
|
|
|
|
|
|
|
|
| |
This doesn't really do anything yet. It's just the CPU detection code, skeleton new .cpp files, and a few little .gyp tweaks.
BUG=skia:4117
Review URL: https://codereview.chromium.org/1255193002
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
SkSurface_Raster snapshots do not lock their backing bitmaps when the
pixel ref is shared - they only lock on deep-copy.
But since for raster surfaces the pixels are always in memory, I think
it would be OK to also lock in the former case.
This allows for optimized (zero-copy) reads of raster surface snapshot
data.
R=reed@google.com
Review URL: https://codereview.chromium.org/1256993002
|
|
|
|
| |
Review URL: https://codereview.chromium.org/1257683004
|