The purpose of this change is to refactor the handling of normal maps out of SkLightingShader, laying the groundwork to eventually allow for multiple normal sources.
This CL's base was the CL for GPU handling: https://codereview.chromium.org/2043393002/
What this CL includes:
- A refactor of the SkLightingShader context's code that deals with reading normals off of a normal map. This is now abstracted out into a NormalSource::Provider class that the context uses.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2050773002
Review-Url: https://codereview.chromium.org/2050773002
Now that GrPathRenderer is using GrShape it is possible to get a key for a path that was computed by applying style to an original path.
This improves path renderer subclass selection, particularly when a post-styled path happens to work with a simpler path renderer (e.g. it is convex). Previously a more expensive path renderer may have applied the style and rendered it (e.g. the distance field PR)
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2064753003
Review-Url: https://codereview.chromium.org/2064753003
- Sk4f would be my choice, but it's not allowed in include/
- SkColor4f and SkPM4f are specified to be unpremultiplied/premultiplied, whereas GrColor (and GrColor4f) are either, depending on context.
This adds 12 bytes to GrPaint. Not sure if we want to pay that price. The precision loss for a single value (vs. in a gradient, etc...) may not justify changing the storage type here. Easy enough to back that part out, while still keeping the 4f intermediate type for the helper math that it adds, and for storage and parameter passing in other locations.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2088303002
Review-Url: https://codereview.chromium.org/2088303002
Ensures that ".get()" always returns null when a container is empty.
Also ensures consistent assert behavior for array counts.
There are still differences in that the malloc variants take a size_t
and the arrays take an int, and that SkAutoSTMalloc defaults to the
stack-allocated buffer wheras the other containers default to null.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2084213003
Review-Url: https://codereview.chromium.org/2084213003
__mulodi4() is roughly,
int64_t __mulodi4(int64_t a, int64_t b, int* overflow) {
int64_t result = a*b;
*overflow = did_overflow(result);
return result;
}
It's used by Clang's __builtin_smulll_overflow(), which is basically the same
except it swaps the positions of the return value and the out parameter.
DNG SDK in turn uses __builtin_smulll_overflow().
When building ARMv7 binaries with Clang, __mulodi4() turns up as a missing symbol.
That's because it's defined in a separate compiler-rt library. I have not been
able to link that. Instead, I've provided our own trivial __builtin_smulll_overflow().
Before this patch both nanobench and DM failed dynamically linking __mulodi4(). After this patch nanobench runs for a while, eventually segfaulting. DM immediately segfaults.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2011073002
Review-Url: https://codereview.chromium.org/2011073002
What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
- add another backend like vs or xcode to GN directly
- intercept via a custom toolchain
- reverse from ninja -t commands
That last option seems kind of fun.
This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
This pulls in some new DEPS:
- build: Chrome's GN configuration, and much more
- buildtools: hashes for gn binary, pulled via hooks
- tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
Have not yet tried building for Windows, Android, or iOS.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
Committed: https://skia.googlesource.com/skia/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17
Review-Url: https://codereview.chromium.org/2087593002
Note that baselines have changed a little since I
recently started using clang.
201295.jpg on HP z620 (300x280)
Skia Xform sRGB Dst Before 0.378 ms
Skia Xform sRGB Dst After 0.322 ms
1.17x
Skia Xform 2.2 Dst Before 0.428 ms
Skia Xform 2.2 Dst After 0.395 ms
1.08x
QCMS Xform 0.418 ms
sRGB Dst vs QCMS 1.30x
2.2 Dst vs QCMS 1.06x
--------------------------------------------
Nexus 6P:
Skia Xform sRGB Dst Before 1.58 ms
Skia Xform sRGB Dst After 1.43 ms
Skia Xform 2.2 Dst Before 2.69 ms
Skia Xform 2.2 Dst After 2.62 ms
Dell Venue 8:
Skia Xform sRGB Dst Before 2.78 ms
Skia Xform sRGB Dst After 2.74 ms
Skia Xform 2.2 Dst Before 3.73 ms
Skia Xform 2.2 Dst After 3.64 ms
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2081933005
CQ_EXTRA_TRYBOTS=client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2081933005
Reason for revert:
gclient not happy on some bots
Original issue's description:
> GN
>
> What we've got here is a little GN MVP. It's lacking any knobs and doesn't yet build anything but libskia, zlib, libpng, and libjpeg-turbo. I've been hopping back and forth between Linux at work and Mac at home. These seem to be at least partially working, enough to build and run cmake/example.cpp.
>
> The xcode backend seems to work. From here, we can start exploring how to handle other backends (cmake,Android make, Google3). There are a couple things I want to try:
> - add another backend like vs or xcode to GN directly
> - intercept via a custom toolchain
> - reverse from ninja -t commands
> That last option seems kind of fun.
>
> This tries to piggyback on Chrome's GN setup as much as possible. Chrome's got quite a lot figured out, and we're basically required to do this if we want to have a single GN build system shareable by Chrome, our bots, and other clients.
>
> This pulls in some new DEPS:
> - build: Chrome's GN configuration, and much more
> - buildtools: hashes for gn binary, pulled via hooks
> - tools/clang: hashes for Chrome's clang, pulled via hooks into third_party/llvm-build
> It additionally symlinks tools/gyp to third_party/externals/gyp. GN pulls some stuff from tools/gyp on Mac.
>
> Have not yet tried building for Windows, Android, or iOS.
>
> BUG=skia:
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2087593002
>
> Committed: https://skia.googlesource.com/skia/+/1d8de594f126b9a80bd8f8fa2005e90faf3b5b17TBR=bsalomon@google.com,mtklein@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Review-Url: https://codereview.chromium.org/2088253002
