If you want to try this out, the DOCS_PREVIEW link is a quickstart.
Are the GrGLCreateNativeInteface_* meant to be part of Skia-the-library
or just used by testing tools? I've got it written here as tool-only,
but we could easily move it to libskia if it's a thing we want to ship.
I'm honestly not sure I understand how this linked before without a definition
of GrGLCreateNativeInterface(). Or are there two, one real and one no-op
default with some sort of weak linking setup? dlopen()?
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2201233003
DOCS_PREVIEW= https://skia.org/user/quick/gn?cl=2201233003
Review-Url: https://codereview.chromium.org/2201233003
Break Skia recipe module into:
- skia_vars: defines and stores variables (eg. paths)
- skia_step: utilities for running Skia steps
- skia_flavor: flavor-specific stuff
- skia: top-level setup, checkout, test/perf steps, etc etc
This establishes a saner dependency structure for the recipes; skia_vars
is at the bottom level, skia_step depends on it, skia_flavor depends on
both of them, skia depends on all of the above, and the recipes
themselves may depend on any or all of them.
Next steps:
- Merge buildbot_spec into skia_vars
- Move test_steps and perf_steps from skia recipe_module into
swarm_test and swarm_perf recipes
- Cleaner checkout_steps process
BUG=skia:5578
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198173002
Review-Url: https://codereview.chromium.org/2198173002
exec_script runs every time gn does, which is explicitly on every one of our
bot runs. That should be enough to obviate the .git/logs/HEAD hack.
Easiest way to do this was to swap around find.py's argument order to allow
multiple search directories. This is the root of all the .gyp changes.
This moves the blacklist into BUILD.gn, which I think is nice.
It expands it a little as we're now searching recursively, into include/gpu/vk
which we can't include safely without the Vulkan SDK.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2205903004
Review-Url: https://codereview.chromium.org/2205903004
(1) Performance is better or stays the same.
(2) Code is split into functions (RasterPipeline-ish
design). IMO, it's not really more or less readable.
But I think it's now much easier add capabilities,
apply optimizations, or do more refactors. Or to
actually use RasterPipeline. I help back from trying
any of these to try to keep this CL sane.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2194303002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Review-Url: https://codereview.chromium.org/2194303002
These files have been renamed and exist only as stubs for transition
reasons. Remove these now unused stubs.
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2197423003
These files are now so badly misnamed that it is causing problems.
The original files are kept as shells until Chromium and PDFium can
be updated. After Chromium and PDFium builds are updated, the old
files will be removed and the cmake and bzl builds will be updated.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2199973002
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-GCC-x86_64-Release-CMake-Trybot,Build-Mac-Clang-x86_64-Release-CMake-Trybot
Review-Url: https://codereview.chromium.org/2199973002
Lessons learned
1. ImageShader (correctly) always compresses (typically via PNG) during serialization. This has the surprise results of
- if the image was marked opaque, but has some non-opaque pixels (i.e. bug in blitter or caller), then compressing may "fix" those pixels, making the deserialized version draw differently. bug filed.
- 565 compressess/decompresses to 8888 (at least on Mac), which draws differently (esp. under some filters). bug filed.
2. BitmapShader did not enforce a copy for mutable bitmaps, but ImageShader does (since it creates an Image). Thus the former would see subsequent changes to the pixels after shader creation, while the latter does not, hence the change to the BlitRow test to avoid this modify-after-create pattern. I sure hope this prev. behavior was a bug/undefined-behavior, since this CL changes that.
BUG=skia:5595
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2195893002
Review-Url: https://codereview.chromium.org/2195893002
No one appears to be using the default 2.2.
This makes SK_GAMMA_SRGB the default / a no-op, which seems more realistic.
Chrome's explicitly setting SK_GAMMA_EXPONENT or SK_GAMMA_SRGB.
We set Android platform explicitly to 1.4.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2198073002
Review-Url: https://codereview.chromium.org/2198073002
SkForceLinking wasn't force-linking the WEBP encoder, or any encoder.
(The others must be explicitly used.)
This should help the GN Debug Perf bots progress past
Running Encode_color_wheel.jpg_WEBP nonrendering
../../../bench/EncoderBench.cpp:58: fatal error: "assert(data)"
On my laptop, a debug nanobench run now finishes.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2196243002
Review-Url: https://codereview.chromium.org/2196243002
