Some users would like to use the empty font manager, but the directory
gont manager brings in extra dependencies to work which would otherwise
be unneeded. Allow these users to build just the bits of code they
actually need.
Change-Id: Ib029ef2682883509bad5a2aa39f1ef55631f4d8a
Reviewed-on: https://skia-review.googlesource.com/8200
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
WindowContext still supports color spaces, but not other color
types. Any off-screen rendering is the app's responsibility.
This change also adds (working) F16 support to viewer. Note that
the previous 10-bit and FP16 support in WindowContext was broken.
There was no code to push the off-screen canvas to the window.
If you ever made it to the unreachable off-screen code path in
createSurface, it would have simply stopped drawing.
The decision to limit the window's gamut to sRGB is mostly driven
by my desire to add real-time editing of gamut. This design lets
us do that, without tearing down and rebuilding the window for
every change. An application could still supply a different gamut
via setDisplayParams and render directly to the back buffer with
proper color correction.
BUG=skia:
Change-Id: I94df35c7a42faee396009acc83683e40bb3c284d
Reviewed-on: https://skia-review.googlesource.com/8153
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Matt Sarett <msarett@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
CQ_INCLUDE_TRYBOTS=skia.primary:Test-iOS-Clang-iPadMini4-GPU-GX6450-arm-Release
Change-Id: I7beadad742bc9444491c7a315a827297a636d70d
Reviewed-on: https://skia-review.googlesource.com/8049
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
BUG=skia:6178
Change-Id: If6f96063fcb4e541da560ff00b925fd8098ce6b9
Reviewed-on: https://skia-review.googlesource.com/7791
Commit-Queue: Ravi Mistry <rmistry@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
- only depend on cpu-features when we know we have an NDK
- disable SkSplicer
Change-Id: I89e4cc70d6ddf0ebb7005d1cb453768d946cd205
Reviewed-on: https://skia-review.googlesource.com/7060
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We can splice these stages if we drop them down to 2 at a time.
Turns out this is significantly (2-3x) faster than the status quo.
SkRasterPipeline_…
…f16_compile 1x …srgb_compile 2.06x …f16_run 3.08x …srgb_run 4.61x
Added a couple ways to detect (likely) the required VFPv4 support:
- use hwcap when available (NDK ≥21, Android framework)
- use cpu-features when not (NDK <21)
The code in SkSplicer_generated.h is ARM, not Thumb2. SkSplicer seems
to be blx'ing into it, so that's great, and we bx lr out. There's no
point in attempting to use Thumb2 in vector heavy code... it'll all be
4 byte anyway.
Follow ups:
- vpush {d8-d9} before the loop, vpop {d8-d9} afterwards,
skip these instructions when splicing;
- (probably) drop jumping stages down to 2-at-a-time also.
Change-Id: If151394ec10e8cbd6a05e2d81808488d743bfe15
Reviewed-on: https://skia-review.googlesource.com/6940
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
i.e. not when generating Android.bp (and in the future, not in Clank builds)
BUG=skia:6065
Change-Id: I52bdd5f01deb5e5b4d9e72bec197a82dc887be88
Reviewed-on: https://skia-review.googlesource.com/6941
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
should just be missing copy_to_executable_mem() / cleanup_executable_mem()
Change-Id: I47d34d4b57a40c07120cca7dc03f6ae22ecbe910
Reviewed-on: https://skia-review.googlesource.com/6854
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Not sure what to do about this long term.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-MSAN
Change-Id: If9e86c285914ce2d8255ac25197845728d7c5d49
Reviewed-on: https://skia-review.googlesource.com/6842
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I also updated the dump feature to work with aarch64, and included comments on how to disassemble an aarch64 dump.
Looking at an aarch64 dump made it immediately obvious that the jump offset was off by 1.
Change-Id: I17fa6ee44779e8be69ab4582e338c88212aba36c
Reviewed-on: https://skia-review.googlesource.com/6841
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Will follow up later with (is_android && target_cpu == "arm64"). Just being cautious.
Change-Id: I32bf48dec55633d6386c66fd0f11fc5616596477
Reviewed-on: https://skia-review.googlesource.com/6834
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
SkSplicer is better.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: I014ec0e9fb00a8a4694d442e672c65402621dc67
Reviewed-on: https://skia-review.googlesource.com/6830
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I think I may have cracked the compile-ahead-of-time-splice-at-runtime nut.
This compiles stages ahead of time using clang, then splices them together at runtime. This means the stages can be written in simple C++, with some mild restrictions.
This performs identically to our Xbyak experiment, and already supports more stages. As written this stands alone from SkRasterPipeline_opts.h, but I'm fairly confident that the bulk (the STAGE implementations) can ultimately be shared.
As of PS 25 or so, this also supports all the stages used by bench/SkRasterPipelineBench.cpp:
SkRasterPipeline_…
400 …f16_compile 1x …f16_run 1.38x …srgb_compile 1.89x …srgb_run 2.21x
That is, ~30% faster than baseline for f16, ~15% faster for sRGB.
Change-Id: I1ec7dcb769613713ce56978c58038f606f87d63d
Reviewed-on: https://skia-review.googlesource.com/6733
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
A little JIT proof of concept for SkRasterPipeline, using xbyak, which is a header-only assembler. It's x86-only, but supports x86 very thoroughly, and it's very user friendly (at least as far as assembler libraries go...).
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD
Change-Id: Ie17e562b0f3fff5914041badfb2c1fe4f86efab8
Reviewed-on: https://skia-review.googlesource.com/5730
Reviewed-by: Herb Derby <herb@google.com>
Reviewed-by: Heather Miller <hcm@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
E.g.
$ ninja -C out push_dm
By default (ninja -C out) everything is built and pushed if skia_android_serial
is set. Dependencies are tracked, so incremental builds push only executables
that have changed.
Change-Id: I586d81791f5f877b173cf61ed68fa9aab96234d2
Reviewed-on: https://skia-review.googlesource.com/6616
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I6e7f41df094ae037538ebd61e40385d7e2e9eb26
Reviewed-on: https://skia-review.googlesource.com/6615
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This template encapsulates two common features of our test apps:
- they set testonly, marking them as safe to use testonly libraries
- they may want instead to be libapp.so on Android.
I plan to follow up to make test_apps push themselves to an Android device when a new argument android_serial is set.
Change-Id: I010d219c14ff6d0cd6a543dd56fd471a67ddb6f1
Reviewed-on: https://skia-review.googlesource.com/6608
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
BUG=skia:
Change-Id: Icf616bec73e81aad97815b519566ff5b9db611e3
Reviewed-on: https://skia-review.googlesource.com/6495
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This forces all of our testing tools to run with the discrete GPU in
laptop systems that have that option.
BUG=skia:
Change-Id: Ibd7629d6de5f063cdf219b3c7469210af5085d90
Reviewed-on: https://skia-review.googlesource.com/6474
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Brian Osman <brianosman@google.com>
There are only a couple of these, primarily focused on index8 srcs and 565 dsts. The burden's starting to outweigh the benefit. No one on the team knows MIPS assembly.
If we're going to try this again, I'd rather we try some sort of SkNx / compiler-intrinsic based approach, probably targeting MIPS SIMD (MSA), not this older instruction set.
We already ignore these files for 64-bit MIPS. This just closes the loop on 32-bit MIPS.
CQ_INCLUDE_TRYBOTS=skia.primary:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD,Build-Ubuntu-Clang-mips64el-Debug-Android,Build-Ubuntu-Clang-mips64el-Release-Android,Build-Ubuntu-Clang-mipsel-Debug-Android,Build-Ubuntu-Clang-mipsel-Release-Android
BUG=skia:6065
Change-Id: Iecac15b56f59625b2e743ea36e7791b90bb0b422
Reviewed-on: https://skia-review.googlesource.com/6353
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Ib831b9a6bcf4f37c0f077b26f68b1cefef81bb73
Reviewed-on: https://skia-review.googlesource.com/6351
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
Motivation: Since I am activly refactoring SkXPS, I will be needing to
add and subtract sources. This is the only way to keep chrome and skia
in sync.
TODO(halcanry): follow up in Chrome build files.
BUG=skia:3495
Change-Id: I2bfcbfce7628c34f9a623c6fa806374a10cdbb75
Reviewed-on: https://skia-review.googlesource.com/6350
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
This reverts commit ada12ab055.
Reason for revert: Google3 needs it:
https://test.corp.google.com/ui#id=OCL:142184832:BASE:142184975:1481839118985:32fde8ef
Original change's description:
> Remove all KTX support
>
> It is untested and unused.
>
> Change-Id: I010ff4ad942738f362d42a99af4edbbb1cb0cd71
> Reviewed-on: https://skia-review.googlesource.com/6142
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Robert Phillips <robertphillips@google.com>
>
TBR=mtklein@chromium.org,mtklein@google.com,robertphillips@google.com,scroggo@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I1ea2f9487eb2212efbfcc514122792b70c9e8737
Reviewed-on: https://skia-review.googlesource.com/6181
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
It is untested and unused.
Change-Id: I010ff4ad942738f362d42a99af4edbbb1cb0cd71
Reviewed-on: https://skia-review.googlesource.com/6142
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Robert Phillips <robertphillips@google.com>
It escaped the chopping block when we deleted the decoder, but it is
currently untested and unused as far as we know. In addition to
removing effectively unsupported code, this simplifies build file
changes (i.e. don't build it on Android framework, but build it
elsewhere) as we narrow our build systems down to one.
Change-Id: I3b960fdcc369fb947be282933ddba48e407ab3ad
Reviewed-on: https://skia-review.googlesource.com/6031
Reviewed-by: Robert Phillips <robertphillips@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Leon Scroggins <scroggo@google.com>
This reverts commit eeb7137a0b.
Reason for revert: well, duh, I guess we'd better update the GYP and Google3 builds...
Original change's description:
> Do not build the ktx encoder for android framework
>
> Move SkKTXImageEncoder.cpp into an optional block, and disable that
> block for the android framework. Use a new define to determine whether
> to define the entry point, rather than using
> SK_BUILD_FOR_ANDROID_FRAMEWORK.
>
> Change-Id: I41103459135af744cf5715f27783c63dc37a7ad1
> Reviewed-on: https://skia-review.googlesource.com/5982
> Commit-Queue: Leon Scroggins <scroggo@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,mtklein@google.com,scroggo@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I8da75db31884b5148f7f85a6a0c3e6913b71cfa8
Reviewed-on: https://skia-review.googlesource.com/6021
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Move SkKTXImageEncoder.cpp into an optional block, and disable that
block for the android framework. Use a new define to determine whether
to define the entry point, rather than using
SK_BUILD_FOR_ANDROID_FRAMEWORK.
Change-Id: I41103459135af744cf5715f27783c63dc37a7ad1
Reviewed-on: https://skia-review.googlesource.com/5982
Commit-Queue: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Instead of relying on cpu-features.c, just do what it does.
Good reading: http://man7.org/linux/man-pages/man3/getauxval.3.html
While it's nice to use the headers when possible, should either of these headers not be available, we can fall back to doing it all manually:
extern "C" uint32_t getauxval(uint32_t)
static const int AT_HWCAP = 16;
static const int HWCAP_CRC32 = (1<<7);
To keep things simple I've slimmed cpu feature detection down to just the features we actually make use of. This removes all runtime feature detection for ARMv7... we expect NEON to be globally available, and so far we haven't used the other FMA/FP16 bits on ARMv7. ARMv8 feature dection remains the same, CRC32 before, CRC32 after. x86 (cpuid-based detection) and MIPS (nothing) are untouched.
We need to keep //third_party/cpu-features for //third_party/libwebp.
Change-Id: I6c96df9a09ae68c8c0e54c1152aa177ba9bafc83
Reviewed-on: https://skia-review.googlesource.com/5800
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
in response to 5784
Change-Id: I3ad34a30743e7ffbd04767668c288a4f884eb19c
Reviewed-on: https://skia-review.googlesource.com/5732
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This spins off parts of 5620 to bake while we work through how to do the rest of libviewer.so -> viewer.apk.
Change-Id: I1cbf135cc952eeb7593e80a5a752dcadaa2dbb00
Reviewed-on: https://skia-review.googlesource.com/5656
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The general idea here is, run GN in --ide=json mode to get most information.
Then, read a couple .gni files to get the rest (platform specific source lists, Android framework defines).
For now, I'm generating Android.bp and SkUserConfig.h. I figure we can do DM and nanobench once these work?
Change-Id: I8e7f60d6572f2d4769760cf872895518a15d841b
Reviewed-on: https://skia-review.googlesource.com/5554
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
The code in views and samplecode wasn't being compiled in. Expand the
scope of the SK_ANGLE define to fix that. Add some missing deps too.
BUG=skia:
Change-Id: Id7b584457a21f171efc2339fb969c550379295e5
Reviewed-on: https://skia-review.googlesource.com/5575
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Also, no more SkImageEncoder class.
SK_SUPPORT_LEGACY_IMAGE_ENCODER_CLASS now only guards some
old API shims.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5006
Change-Id: I3797f584f3e8e12ade10d31e8733163453725f40
Reviewed-on: https://skia-review.googlesource.com/5006
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Reed <reed@google.com>
(re-land 248ff02 & 2cb6cb7, with changes)
- Hide SkImageEncoder class in private header.
- SkImageEncoder::Type becomes SkEncodedImageFormat
- SkEncodedFormat becomes SkEncodedImageFormat
- SkImageEncoder static functions replaced with
single function EncodeImage()
- utility wrappers for EncodeImage() are in
sk_tool_utils.h
TODO: remove link-time registration mechanism.
TODO: clean up clients use of API and flip the flag.
TODO: implement EncodeImage() in chromeium/skia/ext
Change-Id: I47d451e50be4d5c6c130869c7fa7c2857243d9f0
Reviewed-on: https://skia-review.googlesource.com/4909
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Reviewed-on: https://skia-review.googlesource.com/5186
Commit-Queue: Hal Canary <halcanary@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
- Hide SkImageEncoder class in private header.
- SkImageEncoder::Type becomes SkEncodedImageFormat
- SkEncodedFormat becomes SkEncodedImageFormat
- SkImageEncoder static functions replaced with
single function EncodeImage()
- utility wrappers for EncodeImage() are in
sk_tool_utils.h
TODO: remove link-time registration mechanism.
TODO: clean up clients use of API and flip the flag.
TODO: implement EncodeImage() in chromeium/skia/ext
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4909
Change-Id: Ib48b31fdc05cf23cda7f56ebfd67c841c149ce70
Reviewed-on: https://skia-review.googlesource.com/4909
Reviewed-by: Mike Reed <reed@google.com>
Reviewed-by: Leon Scroggins <scroggo@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
This reverts commit c89e2438ae.
Reason for revert:
I'm going to stub this code out in Chrome instead for now. Chrome's not going to land something that looks like this, so I'd rather undo it than leave Skia in this odd state.
Original change's description:
> Turn off /arch:AVX[2] on Windows builds.
>
> This canaries a similar change Chrome may need.
>
> BUG=chromium:666707
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5005
>
> Change-Id: Ibf7f9941968d905d865b9be1e63ebbf768870175
> Reviewed-on: https://skia-review.googlesource.com/5005
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,brucedawson@chromium.org,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I9562f7877749c61f6ba4d48d6c4b557f09876128
Reviewed-on: https://skia-review.googlesource.com/5069
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This leaves libskia as the only thing we build when tools are not enabled (other GN environments like Fuchsia, Flutter, Chrome, or for people using ours and actively disabling tools).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4993
Change-Id: I5acad66c1b068ef81c1a7e292c3524a0b1497b66
Reviewed-on: https://skia-review.googlesource.com/4993
Reviewed-by: Joe Gregorio <jcgregorio@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This canaries a similar change Chrome may need.
BUG=chromium:666707
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=5005
Change-Id: Ibf7f9941968d905d865b9be1e63ebbf768870175
Reviewed-on: https://skia-review.googlesource.com/5005
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
skia.h includes GPU headers. No real point in getting fancy here... if there are no unused parameters in all headers, there are no unused parameters in the subset of non-GPU headers.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4916
Change-Id: Iaaea405633aabcc82e40cd4b1a2286aadd5cea17
Reviewed-on: https://skia-review.googlesource.com/4916
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We already generate skia.h to include all public headers for Fiddle.
This just includes it with -Wunused-parameter turned on as an error.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4901
Change-Id: Ia55a901c09a3c9c9d6d35a43259431dba3532ed9
Reviewed-on: https://skia-review.googlesource.com/4901
Reviewed-by: Derek Sollenberger <djsollen@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 238b820369.
Reason for revert: breaks 32-bit bots, iOS bots, Google3 roll, -ASAN bot.
Original change's description:
> Always build the ANGLE test code. Always build ANGLE on windows and linux.
>
> Make ANGLE test code independent of having ANGLE lib. Make ANGLE test code not include EGL headers.
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4040
>
> DOCS_PREVIEW= https://skia.org/?cl=4040
>
> Change-Id: I7b857e9785246743f53fb969647b1162ce7419ab
> Reviewed-on: https://skia-review.googlesource.com/4040
> Commit-Queue: Brian Salomon <bsalomon@google.com>
> Reviewed-by: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,mtklein@google.com,bsalomon@google.com,reviews@skia.org
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I19bab8c93baebf032f8a4cefbedfe7359317e806
Reviewed-on: https://skia-review.googlesource.com/4758
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
These libraries aren't configured in Fuchsia and would need some GN
reworking to enable. We can wire this up in Fuchsia if/when this
capability when needed.
Change-Id: Iec2d339da07f44516592d6114563a8a4fb59d952
Reviewed-on: https://skia-review.googlesource.com/4744
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
(1) Compile tool with GN.
(2) Rename tool to colorspaceinfo.
(3) Support both images and icc profiles as input.
(4) Print out information on transfer fn in addition to gamut.
TODO: Output graphs of the three transfer fn curves.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4721
Change-Id: I2e75139685ea41446d3ae6f9803c8068ea05661a
Reviewed-on: https://skia-review.googlesource.com/4721
Commit-Queue: Matt Sarett <msarett@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Osman <brianosman@google.com>
When we opt into Lua, this builds SampleLua into SampleApp, and the lua_app and lua_pictures tools.
I've tested this builds with and without skia_use_system_lua on my Mac laptop and Linux desktop.
I've made lua_pictures.cpp's flags static to avoid conflicts with flags in SkCommonFlags.cpp.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4699
DOCS_PREVIEW= https://skia.org/?cl=4699
Change-Id: I8176fd51d8a38746e7d730cfcce66da42b9a015a
Reviewed-on: https://skia-review.googlesource.com/4699
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This reverts commit 7234448c11.
Reason for revert: this enabled tests which are making the bots flaky.
Original change's description:
> GN: define SK_XML to indicate :xml is enabled.
>
> Without this, nothing ever defines SK_XML for dm/DM.cpp, dm/DMSrcSink.cpp, tests/SkDOMTest.cpp or tests/SkPEGTest.cpp.
>
> GYP does something similiar in gyp/xml.gyp.
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4500
>
> Change-Id: I93322722d6d86f5802495d7a2edad2f82ba36f69
> Reviewed-on: https://skia-review.googlesource.com/4500
> Reviewed-by: Hal Canary <halcanary@google.com>
> Commit-Queue: Eric Boren <borenet@google.com>
> Commit-Queue: Mike Klein <mtklein@chromium.org>
>
TBR=mtklein@chromium.org,borenet@google.com,halcanary@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I46c198f4985f6e7f96c07b3100a3877ba46fdb18
Reviewed-on: https://skia-review.googlesource.com/4526
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Without this, nothing ever defines SK_XML for dm/DM.cpp, dm/DMSrcSink.cpp, tests/SkDOMTest.cpp or tests/SkPEGTest.cpp.
GYP does something similiar in gyp/xml.gyp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4500
Change-Id: I93322722d6d86f5802495d7a2edad2f82ba36f69
Reviewed-on: https://skia-review.googlesource.com/4500
Reviewed-by: Hal Canary <halcanary@google.com>
Commit-Queue: Eric Boren <borenet@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This doesn't create any apps or bundles or sign anything, but it all compiles and links.
Note the awkward transitional hack I used to make each tool's tool_main() serve as the real main() again when built with GN, while keeping the existing setup with GYP. Fun...
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4350
Change-Id: I632753d5d8e5848380854f413bf5905d676bfcf4
Reviewed-on: https://skia-review.googlesource.com/4350
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This moves the work of finding headers from `gn gen` time into the action itself. We can do this safely now because we're constructing a skia.h.d deps file, which Ninja uses to track if-these-are-dirty-then-this-is-dirty relationships. Everything can now live in one handy find_headers.py.
Upshot is, `gn gen` runs ~50ms faster, and I think the code's clearer this way too.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4065
Change-Id: I2f1e7adf68be8e961eb77596786a795134bbb9a6
Reviewed-on: https://skia-review.googlesource.com/4065
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
signalBoring() no longer exists. When the fuzzer runs out of randomness,
it just returns 0. Fuzzers should not go into infinite loops if this
happens. do while loops are particularly error-prone.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3963
Change-Id: Iebcfc14cc6b0a19c5dd015cd39875c81fa44003e
Reviewed-on: https://skia-review.googlesource.com/3963
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This extends the pattern in freetype2 to expat, icu, libjpeg-turbo, libpng, libwebp, and zlib, and gives all these an arg to control which to use.
Homebrew doesn't have dng_sdk, piex, or sftnly, or I'd have done the same for them too.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4260
DOCS_PREVIEW= https://skia.org/?cl=4260
Change-Id: I82e780502bf2217336e791787f172a6fc8f55460
Reviewed-on: https://skia-review.googlesource.com/4260
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Hal Canary <halcanary@google.com>
Add BUILD.gn files for dng_sdk and piex and updated BUILD.gn to
build SkRawCodec.
We stopped testing raw images when we switched to GN, so this will
bring back our testing.
Leave SkRawCodec disabled on Windows, where we've had problems in the
past.
Originally landed in issue 4603. Reverted due to build errors.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2463433002
Review-Url: https://codereview.chromium.org/2463433002
Add BUILD.gn files for dng_sdk and piex and updated BUILD.gn to
build SkRawCodec.
We stopped testing raw images when we switched to GN, so this will
bring back our testing.
Leave SkRawCodec disabled on Windows, where we've had problems in the
past.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4063
Change-Id: I956949506200b766a2f7efb18e0486f3a2f93a1c
Reviewed-on: https://skia-review.googlesource.com/4063
Commit-Queue: Leon Scroggins <scroggo@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
This reverts commit a70558e2bb.
Reason for revert:
cmd /c c:\b\s\w\ireutzd9\t\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97/win_sdk/bin/SetEnv.cmd /x86 && c:\b\s\w\ireutzd9\t\depot_tools\win_toolchain\vs_files\95ddda401ec5678f15eeed01d2bee08fcbc5ee97/VC/bin/amd64_x86/cl.exe /nologo /showIncludes /FC @obj/samplecode/SampleApp.SampleApp.obj.rsp /c ../../../samplecode/SampleApp.cpp /Foobj/samplecode/SampleApp.SampleApp.obj /Fd"obj/SampleApp_c.pdb"
c:\b\work\skia\include\views\skoswindow_win.h(18): fatal error C1083: Cannot open include file: 'EGL/egl.h': No such file or directory
I think this is restricted to just 32-bit Windows builds?
Original change's description:
> Add SampleApp support to GN-win
>
> BUG=skia:
>
> GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4062
>
> Change-Id: I88b10748b49adbf57f247b51eec1b9ca86377800
> Reviewed-on: https://skia-review.googlesource.com/4062
> Reviewed-by: Mike Klein <mtklein@chromium.org>
> Reviewed-by: Cary Clark <caryclark@google.com>
> Commit-Queue: Jim Van Verth <jvanverth@google.com>
>
TBR=mtklein@chromium.org,mtklein@google.com,jvanverth@google.com,caryclark@google.com,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: Iba39bab6d3a07a437a86343599e51485d8f4ce93
Reviewed-on: https://skia-review.googlesource.com/4070
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Calling Python to find all these files is convenient, but error-prone. It's easy to forget to call GN again when adding a file. Each of these calls to Python also adds ~50ms to the run time of gn gen, which is small but adds up.
On my desktop, gn gen drops from 600ms to 150ms, noticeably faster.
This leaves one call to find.py for generating skia.h for fiddle. We're not quite sure how to automate that process to happen entirely inside the :skia.h action while maintaining correct dependencies, so I'm leaving it for now.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4036
Change-Id: Ib9d355b97900f29afebc65311ceef50537e46dda
Reviewed-on: https://skia-review.googlesource.com/4036
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Add an interface to decode frames beyond the first in SkCodec, and
add an implementation for SkGifCodec.
Add getFrameData to SkCodec. This method reads ahead in the stream
to return a vector containing meta data about each frame in the image.
This is not required in order to decode frames beyond the first, but
it allows a client to learn extra information:
- how long the frame should be displayed
- whether a frame should be blended with a prior frame, allowing the
client to provide the prior frame to speed up decoding
Add a new fields to SkCodec::Options:
- fFrameIndex
- fHasPriorFrame
The API is designed so that SkCodec never caches frames. If a
client wants a frame beyond the first, they specify the frame in
Options.fFrameIndex. If the client does not have the
frame's required frame (the frame that this frame must be blended on
top of) cached, they pass false for
Options.fHasPriorFrame. Unless the frame is
independent, the codec will then recursively decode all frames
necessary to decode fFrameIndex. If the client has the required frame
cached, they can put it in the dst they pass to the codec, and the
codec will only draw fFrameIndex onto it.
Replace SkGifCodec's scanline decoding support with progressive
decoding, and update the tests accordingly.
Implement new APIs in SkGifCodec. Instead of using gif_lib, use
GIFImageReader, imported from Chromium (along with its copyright
headers) with the following changes:
- SkGifCodec is now the client
- Replace blink types
- Combine GIFColorMap::buildTable and ::getTable into a method that
creates and returns an SkColorTable
- Input comes from an SkStream, instead of a SegmentReader. Add
SkStreamBuffer, which buffers the (potentially partial) stream in
order to decode progressively.
(FIXME: This requires copying data that previously was read directly
from the SegmentReader. Does this hurt performance? If so, can we
fix it?)
- Remove UMA code
- Instead of reporting screen width and height to the client, allow the
client to query for it
- Fail earlier if the first frame AND screen have size of zero
- Compute required previous frame when adding a new one
- Move GIFParseQuery from GIFImageDecoder to GIFImageReader
- Allow parsing up to a specific frame (to skip parsing the rest of the
stream if a client only wants the first frame)
- Compute whether the first frame has alpha and supports index 8, to
create the SkImageInfo. This happens before reporting that the size
has been decoded.
Add GIFImageDecoder::haveDecodedRow to SkGifCodec, imported from
Chromium (along with its copyright header), with the following changes:
- Add support for sampling
- Use the swizzler
- Keep track of the rows decoded
- Do *not* keep track of whether we've seen alpha
Remove SkCodec::kOutOfOrder_SkScanlineOrder, which was only used by GIF
scanline decoding.
Call onRewind even if there is no stream (SkGifCodec needs to clear its
decoded state so it will decode from the beginning).
Add a method to SkSwizzler to access the offset into the dst, taking
subsetting into account.
Add a GM that animates a GIF.
Add tests for the new APIs.
*** Behavior changes:
* Previously, we reported that an image with a subset frame and no transparent
index was opaque and used the background index (if present) to fill the
background. This is necessary in order to support index 8, but it does not
match viewers/browsers I have seen. Examples:
- Chromium and Gimp render the background transparent
- Firefox, Safari, Linux Image Viewer, Safari Preview clip to the frame (for
a single frame image)
This CL matches Chromium's behavior and renders the background transparent.
This allows us to have consistent behavior across products and simplifies
the code (relative to what we would have to do to continue the old behavior
on Android). It also means that we will no longer support index 8 for some
GIFs.
* Stop checking for GIFSTAMP - all GIFs should be either 89a or 87a.
This matches Chromium. I suspect that bugs would have been reported if valid
GIFs started with "GIFVER" instead of "GIF89a" or "GIF87a" (but did not decode
in Chromium).
*** Future work not included in this CL:
* Move some checks out of haveDecodedRow, since they are the same for the
entire frame e.g.
- intersecting the frameRect with the full image size
- whether there is a color table
* Change when we write transparent pixels
- In some cases, Chromium deemed this unnecessary, but I suspect it is slower
than the fallback case. There will continue to be cases where we should
*not* write them, but for e.g. the first pass where we have already
cleared to transparent (which we may also be able to skip) writing the
transparent pixels will not make anything incorrect.
* Report color type and alpha type per frame
- Depending on alpha values, disposal methods, frame rects, etc, subsequent
frames may have different properties than the first.
* Skip copies of the encoded data
- We copy the encoded data in case the stream is one that cannot be rewound,
so we can parse and then decode (possibly not immediately). For some input
streams, this is unnecessary.
- I was concerned this cause a performance regression, but on average the
new code is faster than the old for the images I tested [1].
- It may cause a performance regression for Chromium, though, where we can
always move back in the stream, so this should be addressed.
Design doc:
https://docs.google.com/a/google.com/document/d/12Qhf9T92MWfdWujQwCIjhCO3sw6pTJB5pJBwDM1T7Kc/
[1] https://docs.google.com/a/google.com/spreadsheets/d/19V-t9BfbFw5eiwBTKA1qOBkZbchjlTC5EIz6HFy-6RI/
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=2045293002
Review-Url: https://codereview.chromium.org/2045293002
- Support ObjC / ObjC++
- Build SDL on Mac.
- Build viewer on Mac.
Patched from Jim's CL.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3760
Change-Id: I12663f2ed2969e22f51aefed560fbc22b2524167
Reviewed-on: https://skia-review.googlesource.com/3760
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
We check this define to know which intrinsics we can call safely. The -msse flags set it for us on non-MSVC, but MSVC has no such switch. We do this in GYP (and Chrome's GN) too. No need for any defines on :avx or :hsw targets... the /arch:AVX and /arch:AVX2 do set SK_CPU_SSE_LEVEL for us.
Most directly, this means things like Sk4f::thenElse() will now use blendps when compiled into SkOpts_sse41.cpp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3666
Change-Id: Ie80a8b8e5544250b45cfe51c40604fade06b3ef9
Reviewed-on: https://skia-review.googlesource.com/3666
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
BUG=skia:
Change-Id: Ia0c10db49905fc5a3bdf424c38576e1a6cf09ecf
Reviewed-on: https://skia-review.googlesource.com/3606
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Debugger is the last user of the deprecated SkPaintFilterCanvas
constructor. Stop using it and remove the constructor.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3268
Change-Id: I3e9180d48abdf86cb2c05bd8d95acabcdaa70427
Reviewed-on: https://skia-review.googlesource.com/3268
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Reed <reed@google.com>
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Win-MSVC-x86_64-Release-Vulkan-Trybot;master.client.skia:Test-Win10-MSVC-ShuttleA-GPU-GTX660-x86_64-Debug-Vulkan-Trybot,Perf-Win10-MSVC-ShuttleA-GPU-GTX660-x86_64-Release-Vulkan-Trybot,Perf-Win10-MSVC-ShuttleA-GPU-GTX660-x86_64-Debug-Vulkan-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3421
Change-Id: I7012719fff66778488589ab9c15fd2fa2a109cd1
Reviewed-on: https://skia-review.googlesource.com/3421
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Greg Daniel <egdaniel@google.com>
I really wanted this today, so I got it working again.
Change-Id: I1a37d48d4806198b55c59d1df5ff15a03500195f
Reviewed-on: https://skia-review.googlesource.com/3383
Commit-Queue: Ben Wagner <bungeman@google.com>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Just a simple oversight... this should make Ganesh work.
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Win-MSVC-x86-Debug-Exceptions-Trybot,Build-Win-MSVC-x86_64-Debug-GN-Trybot,Build-Win-MSVC-x86_64-Release-GN-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3382
Change-Id: I90353732a137d004b884cea75f1bd722ede24888
Reviewed-on: https://skia-review.googlesource.com/3382
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Win-MSVC-x86-Debug-GDI-Trybot,Build-Win-MSVC-x86-Release-GDI-Trybot;master.client.skia:Perf-Win-MSVC-GCE-CPU-AVX2-x86_64-Debug-GDI-Trybot,Test-Win-MSVC-GCE-CPU-AVX2-x86_64-Debug-GDI-Trybot,Test-Win-MSVC-GCE-CPU-AVX2-x86_64-Release-GDI-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3324
Change-Id: I3ff2f5d16de9fff7ed77fa5127b96bef55bef957
Reviewed-on: https://skia-review.googlesource.com/3324
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I haven't explicitly confirmed this, but it's likely that today's r12b -> r13 upgrade made this possible.
CQ_INCLUDE_TRYBOTS=master.client.skia.compile:Build-Ubuntu-Clang-mipsel-Debug-GN_Android-Trybot,Build-Ubuntu-Clang-mipsel-Release-GN_Android-Trybot
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3241
Change-Id: I4d19ad48f387d48e0fa4a9f1637c67eb6e1ba4ae
Reviewed-on: https://skia-review.googlesource.com/3241
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I think I'm now at the point of needing to just resolve missing symbols.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=3201
Change-Id: Ib908bd72c23f2d4bafd17182eedcb2fc85c422e5
Reviewed-on: https://skia-review.googlesource.com/3201
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Haswell brought a whole slew of handy new instructions for us (AVX2, FMA, BMI1+BMI2) and also feature F16C, which came one generation earlier on Ivybridge. We work with integers often enough that we really want to target AVX2 instead of AVX, and this means it's pretty practical to ask for all those other goodies along with it.
Chrome's GN files and Google3's BUILD file will need an update, before or after this CL.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2840
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot
Change-Id: I826daf77b5104664c5d31ddaabee347e287b87a2
Reviewed-on: https://skia-review.googlesource.com/2840
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Unlike nanobench this tool has no purpose when built in Debug mode.
Just don't let it happen.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2718
Change-Id: Iaa7b8c44d46024485d4f5ce3d9c3e33d865b99d7
Reviewed-on: https://skia-review.googlesource.com/2718
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Angle's existing GN files only work in Chrome, so I've written a new one.
This won't work on Windows, but our GN build doesn't work on Windows anyway. So this CL is an attempt to get a ahead of that curve on ANGLE. It looks large but fairly straightforward.
Now working on Linux:
$ gn gen angle --args=skia_use_angle=true
$ ninja -C angle
$ angle/dm --config angle-gl --src gm -w dm-out
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2361983002
Review-Url: https://codereview.chromium.org/2361983002
I trimmed the libmicrohttpd sources and defines down to the minimum needed to build and run. This builds and runs on Linux and Android for me.
Request.h was missing an include for SkTypes.h, which supplies the default for SK_GPU_SUPPORTED if not otherwise defined.
To build on Android, exit() -> _exit().
build.py was unused.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2367513002
NOTREECHECKS=true
Review-Url: https://codereview.chromium.org/2367513002
I was just lazy disabling this before. It turns out to not be difficult.
This gets us slightly better testing out of the NoGPU bot, as we now know
not only that Skia compiles, but also that DM and nanobench can link (and
thus that Skia's got enough compiled in it to be a coherent library).
skpbench requires GPU support.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2356283002
Review-Url: https://codereview.chromium.org/2356283002
is_skia_standalone will be defined and set to true iff we're using our
standalone BUILDCONFIG.gn. Any other build (Fuchsia, Chrome, Pdfium)
will have their own BUILDCONFIG.gn, which presumably does not define
is_skia_standalone.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2357963002
Review-Url: https://codereview.chromium.org/2357963002
Chromium needs to be able to set up their build such that the globals
continue existing but the SkFontMgr::Factory can be defined separately.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2346333002
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/2346333002
skpbench is a benchmarking suite for skps that aims to generate 100%
repeatable results. The initial commit consists of three parts:
skpbench
A minimalist program whose sole purpose is to open an skp file,
benchmark it on a single config, and exit. No tiling, looping, or
other fanciness is used; it just draws the skp whole into a size-
matched render target and syncs the GPU after each draw.
Limiting the entire process to a single config/skp pair helps to keep
the results repeatable.
skpbench.py
A wrapper to execute the skpbench binary with various configs and skps.
It also monitors the output in order to filter out and re-run results
with an unacceptable stddev.
In the future this script will lock down and monitor clocks and
temperatures.
parseskpbench.py
A utility for parsing skpbench output into a spreadsheet.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2341823002
Review-Url: https://codereview.chromium.org/2341823002
Android API >= 24 implies Vulkan support, so we can have a more useful default here than 'false'. If for some reason you wanted to turn it off, you can still override skia_use_vulkan.
The defined(ndk_api) guards other users of our GN files (Fuchsia) who may not have an ndk_api argument defined in their BUILDCONFIG.gn.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2347843003
Review-Url: https://codereview.chromium.org/2347843003
... and use it to control debug symbols and SK_ALLOW_STATIC_GLOBAL_INITIALIZERS.
This will most directly have the effect of disabling GLProgramsTest and a bunch
of similar failing Vk tests on Android.
Hopefully this makes the N7 trybot go green, keeping the N5 trybot green. Just running the N10 for fun.
(is_official_build is how Chrome terms this sort of ReleaseForReal build.)
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2340723003
Review-Url: https://codereview.chromium.org/2340723003
Android's the easiest place to start supporting Vulkan, so it's up first.
ndk_api becomes user-specifiable so that the Vulkan bots can kick it up
to 24, the first release supporting Vulkan. The defaults remain the same:
18 for 32-bit and 21 for 64-bit, the first release supporting 64-bit.
To test this, I set ndk_api=24 and skia_use_vulkan=true in GN, then
$ ninja -C out dm; and droid out/dm --config vk --src gm
Seems to work! Bot scripts to follow.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2336343002
Review-Url: https://codereview.chromium.org/2336343002
Kind of a big change, to connect several new bits into something useful:
* ID tracking & lookup
* new asPaint() node virtual to support shader (and in the future filter) based paint servers
* <defs>, <linearGradient> and <stop> element support
* 'href', 'offset', 'stop-color', 'stop-opacity' attribute support
* IRI/FuncIRI and rgb(...) parsing
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2327233003
Review-Url: https://codereview.chromium.org/2327233003
What do you think of this? It's basically what you wrote, factored differently.
Flipping on skia_use_freetype will enable the SkFontHost_Freetype*.cpp files
via the :typeface_freetype target.
Then we just pull out the SkFontMgr Fuchsia wants to use into its own little
:fontmgr_fuchsia target. No major difference here, except the availability
of freetype headers, etc, is a bit more tightly scoped to just those that
need them.
We (obviously?) don't have Fuchsia builders, so I've got to rely on you for sanity testing this.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2333913002
Review-Url: https://codereview.chromium.org/2333913002
The SK_GAMMA_ defines change text rendering on Android.
This is how they're set in GYP for Android... everyone else is default (sRGB).
Linking AndroidSkDebugToStdOut.o causes SkDebugf to go to both logcat and
stdout on Android. Without it, it only goes to logcat. The file has no effect
on non-Android platforms.
BUG=skia:
Review-Url: https://codereview.chromium.org/2323353002
This makes skia_use_fontconfig=false build on Linux. Instead of using
fontconfig it looks in /usr/share/fonts.
That alone is a nice feature to have, but it's mostly relevant for MSAN,
where we can't link against any uninstrumented system libraries.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2318133003
Review-Url: https://codereview.chromium.org/2318133003
This file will be imported by Chrome to access the sources lists.
Once Chrome is updated to use this file, changes to the skia .gypi layout can
be done entirely within the skia repository as long as the resulting lists
produced by the new .gni file have the same name.
Marks skia_for_chromium_defines as obsolete and moves the definition into the new .gni file. We can remove the .gypi file when Chrome is updated.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2302803005
Review-Url: https://codereview.chromium.org/2302803005
This way you don't need to set LSAN_SUPPRESSIONS in your environment...
sort of foolproof this way.
I _think_ the strdup() business from skia:2916 is actually rooted in
libfontconfig, so one suppression should cover both old ones.
I'll leave the file empty until I clean up mention of it in bot recipes.
BUG=skia:2916
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2295153003
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-Clang-GCE-CPU-AVX2-x86_64-Debug-ASAN-Trybot
Review-Url: https://codereview.chromium.org/2295153003
Also make sources_when_disabled and public_defines optional arguments.
These are the two mechanisms code uses to turn itself off...
probably at most one is ever used per optional.
Update fiddle to not crash when there's no PDF backend.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2292343003
Review-Url: https://codereview.chromium.org/2292343003
This fixes this warning-as-error, so we don't have to stifle it any more:
error: 'register' storage class specifier is deprecated and incompatible with C++1z [-Werror,-Wdeprecated-register]
Tested by building for mipsel via GN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2289293002
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/2289293002
Once you have downloaded an android NDK, you can set the ndk GN arg to use it.
E.g. my gn.args looks like:
is_debug = false
ndk = "/opt/android-ndk"
This should be enough to get you going for an arm64 build. You ought to be able to tweak that to other architectures by changing target_cpu to "arm", "x86", "x86-64", etc. That won't quite work until I follow this up a bit, but the skeleton is there.
This is enough to get me compiled, linked, and running to completion on my N5x.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2275983004
Review-Url: https://codereview.chromium.org/2275983004
No more:
#include SK_SFNTLY_SUBSETTER
#include ZLIB_INCLUDE
Also, rename SK_SFNTLY_SUBSETTER to SK_PDF_USE_SFNTLY
to follow my pattern of prefixing SkPDF-specific defines
with 'SK_PDF_'.
The ZLIB_INCLUDE define is no longer is used by anyone.
TODO: rename Sfntly to something pronounceable.
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2273343002
Review-Url: https://codereview.chromium.org/2273343002
- Use options' template pattern for opts too.
- Simplify opt's and options' configs... they should all be the same.
- When building a static-library component in our GN environment (i.e. libskia.a),
make it a complete static lib, fully containing its transitive deps.
- It has not proved useful to override ar.
TBR=jcgregorio@google.com
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2278673002
Review-Url: https://codereview.chromium.org/2278673002
Our tools use third-party libraries pretty freely, some of which may not
be available in other GN environments (e.g. Fuchsia). Most can also not
function when Skia is built as a shared library.
fiddle stands alone as the exception to both those points: it depends on
only Skia, and works fine with both a shared or static library.
So guard everything but fiddle with this flag skia_enable_tools, disabled
when we're building for Fuchsia or when we're build a shared library.
This CL has a couple of little tweaks to Fiddle to keep it working:
- divorce it from :tool_utils, instead just building SkForceLinking.cpp itself;
- fix up a buggy rebase_path() that was accidentally working when we depended
on :tool_utils;
- drop test_only: it now only requires production-code dependencies.
The SkImageEncoder Create* methods need to be SK_API if we want SkForceLinking
to work across .so's. Without this, SkForceLinking needs to be part of Skia; it
can't be part of the application using Skia.
The rest is mostly just a re-indent under if (skia_enable_tools),
courtesy of gn format.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2273823003
No public API changes.
TBR=reed@google.com
Review-Url: https://codereview.chromium.org/2273823003
This will be handy for folks who don't have libwebp, like Fuchsia.
I convinced myself that this is done right by:
- building in all three modes (default and explicitly set both ways);
- looking at verbose Ninja logs to see the presence/lack of SK_HAS_WEBP_LIBRARY;
- running dm -m Codec, which passes with libwebp and segfault without it.
If this is viable, I intend to make all third-party dependencies optional
and follow this pattern. :skia should link and degrade gracefully without
any of //third_party. It's okay for tools to have hard third-party
dependencies; we just need them to get past the `gn gen` stage without them.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2270693004
Review-Url: https://codereview.chromium.org/2270693004
We might as well match the folks who are using our GN files now.
We've got plenty of strategies in our pocket for when we try to move Chrome
onto our GN files (and who knows, there may be even a new better way by then):
* Same sort of rename in Chrome's third_party
* Aliased targets via //build/secondary in Chrome.
* Indirection via build_overrides
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2265503002
Review-Url: https://codereview.chromium.org/2265503002
About 9x faster than Murmur3 for long inputs.
Most of this is a mechanical change from SkChecksum::Murmur3(...) to SkOpts::hash(...).
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2208903002
CQ_INCLUDE_TRYBOTS=master.client.skia:Test-Ubuntu-GCC-GCE-CPU-AVX2-x86_64-Release-SKNX_NO_SIMD-Trybot;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/2208903002
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
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
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
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
Add nanobench, and while we're at it monobench to show off how cool
source_sets are... the bench files are only built once then linked
into both binaries. With GYP we build them twice. :/ Same deal
for GMs between nanobench and DM... build once, link twice.
nanobench uses SkImageEncoder to encode its .pngs, which requires
we link in the image encoders, which requires we get them all in.
That's the bulk of this.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2193513002
Review-Url: https://codereview.chromium.org/2193513002
These flags hide symbols that are not marked with SK_API when linked into a
shared library. There's nominally no effect on static linking, but I'm
pretty sure the Mac linker takes some advantage of this too to run faster.
This makes component-build DM no longer link: it uses many non SK_API APIs.
Fiddle in contrast is just fine with our public APIs, so no need to restrict that.
It'll be fun finding out which of our other tools go which ways.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2180383003
Review-Url: https://codereview.chromium.org/2180383003
This builds, links, and runs on Linux. Have not tried Mac.
I've tested is_debug={true,false} and is_component_build.
It's neat that the component build DM works, but it's also an indication I've missed an essential flag or two... it shouldn't work. :)
The GPU backend isn't working yet, but all the software configurations I've tried look good.
This fleshes out all the other parts of SkCodec too... I noticed we weren't able to decode gifs or webp.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2188643002
Review-Url: https://codereview.chromium.org/2188643002
- Make fiddle build on Mac (skipping GL).
- Now that we're building in SkCodec, we depend on libpng and libjpeg-turbo unconditionally, not just on Linux.
- Re-arrange third_party a bit so that our targets are Fuchsia/Chrome compatible.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2184133002
NOTREECHECKS=true
This doesn't affect Chrome/Blink, so landing through the closed tree.
Review-Url: https://codereview.chromium.org/2184133002
This sketches out what a world without Chrome's GN configs would look like.
Instead of DEPSing in build/, we now host our own gypi_to_gn.py.
The symlink from skia/ to . lets us run gclient hooks when the .gclient file is in the directory above skia/ or inside skia/. That means we don't need gn.py anymore.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2167163002
Review-Url: https://codereview.chromium.org/2167163002
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
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
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
Review-Url: https://codereview.chromium.org/2087593002
