This almost gets gms to be iwyu clean. The last bit is around gm.cpp
and the tracing framework and its use of atomic. Will also need a way
of keeping things from regressing, which is difficult due to needing to
do this outside-in.
Change-Id: I1393531e99da8b0f1a29f55c53c86d53f459af7d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/211593
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
Current strategy: everything from the top
Things to look at first are the manual changes:
- added tools/rewrite_includes.py
- removed -Idirectives from BUILD.gn
- various compile.sh simplifications
- tweak tools/embed_resources.py
- update gn/find_headers.py to write paths from the top
- update gn/gn_to_bp.py SkUserConfig.h layout
so that #include "include/config/SkUserConfig.h" always
gets the header we want.
No-Presubmit: true
Change-Id: I73a4b181654e0e38d229bc456c0d0854bae3363e
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/209706
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Hal Canary <halcanary@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Reviewed-by: Florin Malita <fmalita@chromium.org>
sk_tool_utils doesn't really fit the naming convention
the rest of code under tools/ tends to use.
Change-Id: I45326a174101c6eb4b6149e9c742f658f2fd23b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202313
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
This allows for testing falling into various buckets in the gpu
fallbacks.
Change-Id: Ia0c319a6bdd03c5cdece1ce83ab228c1a3a7c46d
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/199420
Reviewed-by: Jim Van Verth <jvanverth@google.com>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Ben Wagner <bungeman@google.com>
We don't need this name munging since the
native/non-native font bots split.
Change-Id: I0e64feb08441ece8e0e4be0a70b812220aa8385a
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/199300
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@google.com>
Bug: skia:8773
Change-Id: I82b1f22f300eadc93f79a35a1638b7eb6376169a
Reviewed-on: https://skia-review.googlesource.com/c/193031
Commit-Queue: Mike Reed <reed@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Adapting gray to 565 will add a noticeable purple/green tint.
I'd rather only the 565 images in Gold were tainted with that.
Change-Id: Ib09e92b2f78c6de086345124e9eefeb31bbb5fa8
Reviewed-on: https://skia-review.googlesource.com/147422
Commit-Queue: Mike Klein <mtklein@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Right now the native font platform implies what emoji formats are
supported, and we hope to support more than one per platform. Let's
get these formats out of the name.
As with most other font-y things, only the NativeFont bots are going to
get back anything interesting now. The others will see no emoji font
and an empty emoji sample text string.
I'm going to look at a pre-baked testing SkTypeface that serves as an
emoji font for the non-NativeFont bots next.
Change-Id: Ie1374fc0e988bfe20ae21208e2f7e0a66a68fcb1
Reviewed-on: https://skia-review.googlesource.com/71762
Reviewed-by: Ben Wagner <bungeman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I310f39d8a470729d5525fb4f82e6a45b882313f3
Reviewed-on: https://skia-review.googlesource.com/71341
Commit-Queue: Hal Canary <halcanary@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Ben Wagner <bungeman@google.com>
gm.h includes sk_tool_utils.h but does not use it.
The bulk of this CL makes each gm that uses sk_tool_utils include it.
sk_tool_utils.h also provided SkRandom and SkTDArray,
so a couple GMs add those headers too.
Change-Id: Ieb2a7c542f0ca89c3223f744fc11b0ff37af36c1
Reviewed-on: https://skia-review.googlesource.com/10014
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
'static const' means, there must be at most one of these, and initialize it at
compile time if possible or runtime if necessary. This leads to unexpected
code execution, and TSAN* will complain about races on the guard variables.
Generally 'constexpr' or 'const' are better choices. Neither can cause races:
they're either intialized at compile time (constexpr) or intialized each time
independently (const).
This CL prefers constexpr where possible, and uses const where not. It even
prefers constexpr over const where they don't make a difference... I want to have
lots of examples of constexpr for people to see and mimic.
The scoped-to-class static has nothing to do with any of this, and is not changed.
* Not yet on the bots, which use an older TSAN.
BUG=skia:
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=2300623005
Review-Url: https://codereview.chromium.org/2300623005
