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>
Turns out lots of tools had two copies of many of these flags.
Some GN and .cpp file refactoring to make sure when flags are
present in a binary, they do something in that binary.
I think this finally finishes the flag refrag.
Change-Id: I01488e37ab73a5c4361786863ddb137a7f1095b1
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203420
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
These are only used by DM and nanobench,
and sometimes even do substantially different things...
Change-Id: I973f3938fbae1fd1b19d876fa6a90122fc55d48c
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203167
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
In the end only DM and skia_test really use it.
- nanobench used --veryVerbose in a silly superficial way
- gm/fontmgr.cpp is probably clearer using its own flag
- the change to StrokerTest should be a near noop...
reporter->verbose() is set by --veryVerbose in both
DM and skia_test.cpp. One of the checks tested
FLAGS_verbose, but I feel like that was probably a typo.
Change-Id: I2601d243b8200b3bb7a16478dfbce14001c4a191
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/203180
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Like any normal variable, flags can be made file-scoped static,
and like any normal variable, mostly they should be if they can.
This CL converts most flags to be static, if only so that the
ones that do cross files stand out more clearly, and so that
there's more examples of static flags through the codebase for
people to ape.
Change-Id: Ibb5ddd7aa09fce073d0996ac3ef0487b078b7d79
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202800
Commit-Queue: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Auto-Submit: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
The command line flag package is tool-only, not part of Skia per se,
and does not need an Sk prefix to avoid naming conflicts.
And git clang-format.
Change-Id: Ida8477779e51750ed0475590ed2454841b23d6ea
Reviewed-on: https://skia-review.googlesource.com/c/skia/+/202307
Auto-Submit: Mike Klein <mtklein@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Change-Id: I4960b1cd055daf44637e95825f82cb7fe2ce134a
Reviewed-on: https://skia-review.googlesource.com/c/174285
Commit-Queue: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Osman <brianosman@google.com>
Dump as hex instead of SVG to more accurately
capture pathops tests.
Use SkBits2Float to reconstruct SkScalar data.
Exclude tests with conics since, for the moment,
pathkit maps conics to quads.
R=kjlubick@google.com
Bug: skia:
Change-Id: Iba2836bde8f737f42c8da31cc26e83ce55de924a
Reviewed-on: https://skia-review.googlesource.com/146165
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Cary Clark <caryclark@skia.org>
pathops_unittest -J dump.json
now generates both Op() and Simplify() tests and results.
Also, make json names unique. While this may not be necessary,
duplicate names may make debugging failing tests more difficult.
R=kjlubick@google.com
Bug: skia:
Change-Id: I2eed5a8141764a0ad993fb9a09c23b7d90d65048
Reviewed-on: https://skia-review.googlesource.com/146100
Commit-Queue: Cary Clark <caryclark@skia.org>
Commit-Queue: Kevin Lubick <kjlubick@google.com>
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
./out/skia/pathops_unittest -J dump.json
will write all Op tests to a JSON file. Since this
will run single threaded, this can take a while,
and generates a 500M file.
A reasonable subset is
./out/skia/pathops_unittest -J dump.json -m PathOpsOp$
around 275K.
This is in service of pathkit.
R=kjlubick@google.com
Bug: skia:
Change-Id: I7e0771639e29755c00036f335a531403044d9d30
Reviewed-on: https://skia-review.googlesource.com/145737
Commit-Queue: Cary Clark <caryclark@skia.org>
Auto-Submit: Cary Clark <caryclark@skia.org>
Reviewed-by: Kevin Lubick <kjlubick@google.com>
Most of this is (obviously) not necessary to do, but once
I started, I figured I'd just get it all. Tools (nanobench,
DM, skiaserve), all GMs, benches, and unit tests, plus support
code (command line parsing and config stuff).
This is almost entirely mechanical.
Bug: skia:
Change-Id: I209500f8df8c5bd43f8298ff26440d1c4d7425fb
Reviewed-on: https://skia-review.googlesource.com/131153
Reviewed-by: Mike Klein <mtklein@google.com>
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
(Found by latest version of clang)
Bug: skia:
Change-Id: Ia24e023ed0cd8296276dbdd6abff5e0017de02d3
Reviewed-on: https://skia-review.googlesource.com/82741
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Brian Osman <brianosman@google.com>
This is to alleviate problems due to the command buffer getting bent out of shape when the current
OpenGL context is switched out from under it (because we ran a test with a native GL context). This,
however is not a full solution. More changes will be required to ensure that after running each
command buffer or native test we bind the null context. This does allow us to take a step in that
direction without breaking anything too badly. Moreover, there is no real benefit to reusing a
GrContextFactory.
Modifies DEF_GPUTEST to take GrContextOptions rather than a factory to use. Tests were already using
their own factories anyway.
In tests that use GrContextFactory the factory instance is moved to the inner loop.
Modifies gpucts and skia_test to not use persistent GrContextFactories.
Change-Id: Ie7a36793545c775f2f30653ead6fec93a3d22717
Reviewed-on: https://skia-review.googlesource.com/71861
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Brian Salomon <bsalomon@google.com>
The weird foo_mains are no longer needed when we build with GN.
CQ_INCLUDE_TRYBOTS=skia.primary:Build-Mac-Clang-arm-Debug-iOS
Change-Id: Iae50696741e0dc277d96dda4968a1ae41cb17c8a
Reviewed-on: https://skia-review.googlesource.com/8064
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Stephan Altmueller <stephana@google.com>
This reverts commit d2eb581ebc.
Reason for revert: broke Google3 MSAN run of dm
Original change's description:
> offset angle check edge in common
>
> When curves cross, their intersection points may be nearby, but not exactly the same.
> Sort the angles formed by the crossing curves when all angles don't have the same
> origin.
>
> This sets up the framework to solve test case that currently fail (e.g., joel6) but
> does not fix all related test cases (e.g., joel9).
>
> All older existing test cases, including extended tests, pass.
>
> Rework the test framework to better report when tests expected to produce failing
> results now pass.
>
> Add new point and vector operations to support offset angles.
>
> TBR=reed@google.com
> BUG=skia:6041
>
> Change-Id: I67c651ded0a25e99ad93d55d6a35109b3ee3698e
> Reviewed-on: https://skia-review.googlesource.com/6624
> Commit-Queue: Cary Clark <caryclark@google.com>
> Reviewed-by: Cary Clark <caryclark@google.com>
>
TBR=caryclark@google.com,reviews@skia.org
# Not skipping CQ checks because original CL landed > 1 day ago.
BUG=skia:6041
Change-Id: I43db0808522ac44aceeb4f70e296167ea84a3663
Reviewed-on: https://skia-review.googlesource.com/7373
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
When curves cross, their intersection points may be nearby, but not exactly the same.
Sort the angles formed by the crossing curves when all angles don't have the same
origin.
This sets up the framework to solve test case that currently fail (e.g., joel6) but
does not fix all related test cases (e.g., joel9).
All older existing test cases, including extended tests, pass.
Rework the test framework to better report when tests expected to produce failing
results now pass.
Add new point and vector operations to support offset angles.
TBR=reed@google.com
BUG=skia:6041
Change-Id: I67c651ded0a25e99ad93d55d6a35109b3ee3698e
Reviewed-on: https://skia-review.googlesource.com/6624
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
The ASAN fuzzer on chrome caught a hanging state.
To capture the data, allow the pathops client debugging
to run in a release build.
TBR=reed@google.com
BUG=665295
GOLD_TRYBOT_URL= https://gold.skia.org/search?issue=4834
Change-Id: I6b2c2baabd63994f63aa730d2ee7828986b5ab89
Reviewed-on: https://skia-review.googlesource.com/4834
Commit-Queue: Cary Clark <caryclark@google.com>
Reviewed-by: Cary Clark <caryclark@google.com>
The following are currently unused in Android, Google3, Chromium, and Mozilla:
- SkEvent
- SkTime::GetMSecs
- SK_TIME_FACTOR (also unused in Skia)
- SkAutoTime
I left uses of SkMSec more-or-less intact for SkEvent, SkAnimator, and SkInterpolator. SkInterpolator is used in Chromium, so I did not want to change the API. The views/ and animator/ code is crufty, so it didn't seem worthwhile to refactor it. Instead, I added SkEvent::GetMSecsSinceStartup, which is likely to be adequate for use in SampleApp.
I also left SkMSec where it is used to measure a duration rather than a timestamp. With the exception of SkMovie, which is used in Android, all of the uses appear to measure the execution time of a piece of code, which I would hope does not exceed 2^31 milliseconds.
Added skiatest::Timer to support a common idiom in tests where we want to measure the wallclock time in integer milliseconds. (Not used in tests/PathOpsSkpClipTest.cpp because it redefines things in Test.h.)
Removed tabs in tests/StrokerTest.cpp.
BUG=skia:4632
GOLD_TRYBOT_URL= https://gold.skia.org/search2?unt=true&query=source_type%3Dgm&master=false&issue=1811613004
Review URL: https://codereview.chromium.org/1811613004
Iterating through the 903K skps that represent the
imagable 1M top web pages triggers a number of
bugs, some of which are addressed here.
Some web pages trigger intersecting cubic
representations of arc with their conic
counterparts. This exposed a flaw in coincident
detection that caused an infinite loop. The loop
alternatively extended the coincident section and,
determining the that the bounds of the curve pairs
did not overlap, deleted the extension.
Track the number of times the coincident detection
is called, and if it exceeds an empirically found
limit, assume that the curves are coincident and
force it to be so.
The loop count limit can be determined by enabling
DEBUG_T_SECT_LOOP_COUNT and running all tests. The
largest count is reported on completion.
Another class of bugs was caused by concident
detection duplicating nearly identical points that
had been merged earlier. To track these bugs, the
'handle coincidence' code was duplicated as a
const debug variety that reported if one of a
dozen or so irregularities are present; then it is
easier to see when a block of code that fixes one
irregularity regresses another.
Creating the debug const code version exposed some
non-debug code that could be const, and some that
was experimental and could be removed. Set
DEBUG_COINCIDENCE to track coincidence health and
handling.
For running on Chrome, DEBUG_VERIFY checks the
result of pathops against the same operation
using SkRegion to verify that the results are
nearly the same.
When visualizing the pathops work using
tools/pathops_visualizer.htm, set
DEBUG_DUMP_ALIGNMENT to see the curves after
they've been aligned for coincidence.
Other bugs fixed include detecting when a
section of a pair of curves have devolved into
lines and are coincident.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/1394503003
Use the form SkDebugf("%s", arbitraryString) instead of
SkDebugf(arbitraryString).
Fixes the case where SkString::appendf-ing a string with "%%" and then
printing the string with SkDebugf would cause uninitialized read and
corrupted debug print.
ninja -C out/Debug tools && valgrind --leak-check=full
./out/Debug/render_pictures --config gpu -w q -r ...
...
==7307== Conditional jump or move depends on uninitialised value(s)
==7307== at 0x6908475: __printf_fp (printf_fp.c:1180)
==7307== by 0x6904267: vfprintf (vfprintf.c:1629)
==7307== by 0x6906E53: buffered_vfprintf (vfprintf.c:2313)
==7307== by 0x690188D: vfprintf (vfprintf.c:1316)
==7307== by 0x67E8F5: SkDebugf(char const*, ...) (SkDebug_stdio.cpp:18)
==7307== by 0x7983F1: GrContext::printCacheStats() const (GrTest.cpp:54)
==7307== by 0x408ECF: tool_main(int, char**) (render_pictures_main.cpp:480)
==7307== by 0x40913E: main (render_pictures_main.cpp:511)
==7307==
Budget: 2048 items 100663296 bytes
Entry Count: current 652 (651 budgeted, 0 wrapped, 297 locked, 638 scratch 32 0.000000ull), high 652
Entry Bytes: current 51087658 (budgeted 49826658, 49 0.000000ull, 1261000 unbudgeted) high 51087658
(observe "ull" instead of "% full")
(from mtklein)
This CL is not editing public API.
TBR=reed@google.com
Review URL: https://codereview.chromium.org/943453002
skiatest::Test class is now a simple struct. Some
functionalty, such as counting errors or timing is now
handled elsewhere.
skiatest:Reporter is now a simpler abstract class. The two
implementations handle test errors.
DM and pathops_unittest updated.
Review URL: https://codereview.chromium.org/830513004
This fixes every case where virtual and SK_OVERRIDE were on the same line,
which should be the bulk of cases. We'll have to manually clean up the rest
over time unless I level up in regexes.
for f in (find . -type f); perl -p -i -e 's/virtual (.*)SK_OVERRIDE/\1SK_OVERRIDE/g' $f; end
BUG=skia:
Review URL: https://codereview.chromium.org/806653007
Add skiatest::Failure to keep track of data about a test failure.
Reporter::reportFailed and ::onReportFailed now take Failure as a
parameter. This allows the implementation to treat the failure as it
wishes. Provide a helper to format the failure the same as prior to
the change.
Update the macros for calling reportFailed (REPORTER_ASSERT etc) to
create a Failure object.
Convert a direct call to reportFailed to the macro ERRORF.
Write Failures to Json.
Sample output when running dm on the dummy test crrev.com/705723004:
{
"test_results" : {
"failures" : [
{
"condition" : "0 > 3",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 10,
"message" : ""
},
{
"condition" : "false",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 4,
"message" : ""
},
{
"condition" : "1 == 3",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 5,
"message" : "I can too count!"
},
{
"condition" : "",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 6,
"message" : "seven is 7"
},
{
"condition" : "1 == 3",
"file_name" : "../../tests/DummyTest.cpp",
"line_no" : 14,
"message" : "I can too count!"
}
]
}
}
Report all of the failures from one test.
Previously, if one test had multiple failures, only one was reportered.
e.g:
Failures:
test Dummy: ../../tests/DummyTest.cpp:6 seven is 7
test Dummy2: ../../tests/DummyTest.cpp:10 0 > 3
test Dummy3: ../../tests/DummyTest.cpp:14 I can too count!: 1 == 3
3 failures.
Now, we get all the messages:
Failures:
test Dummy: ../../tests/DummyTest.cpp:4 false
../../tests/DummyTest.cpp:5 I can too count!: 1 == 3
../../tests/DummyTest.cpp:6 seven is 7
test Dummy2: ../../tests/DummyTest.cpp:10 0 > 3
test Dummy3: ../../tests/DummyTest.cpp:14 I can too count!: 1 == 3
3 failures.
(Note that we still state "3 failures" because 3 DM::Tasks failed.)
BUG=skia:3082
BUG=skia:2454
Review URL: https://codereview.chromium.org/694703005
SkTaskGroup is like SkThreadPool except the threads stay in
one global pool. Each SkTaskGroup itself is tiny (4 bytes)
and its wait() method applies only to tasks add()ed to that
instance, not the whole thread pool.
This means we don't need to bring up new thread pools when
tests themselves want to use multithreading (e.g. pathops,
quilt). We just create a new SkTaskGroup and wait for that
to complete. This should be more efficient, and allow us
to expand where we use threads to really latency sensitive
places. E.g. we can probably now use these in nanobench
for CPU .skp rendering.
Now that all threads are sharing the same pool, I think we
can remove most of the custom mechanism pathops tests use
to control threading. They'll just ride on the global pool
with all other tests now.
This (temporarily?) removes the GPU multithreading feature
from DM, which we don't use.
On my desktop, DM runs a little faster (57s -> 55s) in
Debug, and a lot faster in Release (36s -> 24s). The bots
show speedups of similar proportions, cutting more than a
minute off the N4/Release and Win7/Debug runtimes.
BUG=skia:
Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/531653002
Reason for revert:
Leaks, leaks, leaks.
Original issue's description:
> SkThreadPool ~~> SkTaskGroup
>
> SkTaskGroup is like SkThreadPool except the threads stay in
> one global pool. Each SkTaskGroup itself is tiny (4 bytes)
> and its wait() method applies only to tasks add()ed to that
> instance, not the whole thread pool.
>
> This means we don't need to bring up new thread pools when
> tests themselves want to use multithreading (e.g. pathops,
> quilt). We just create a new SkTaskGroup and wait for that
> to complete. This should be more efficient, and allow us
> to expand where we use threads to really latency sensitive
> places. E.g. we can probably now use these in nanobench
> for CPU .skp rendering.
>
> Now that all threads are sharing the same pool, I think we
> can remove most of the custom mechanism pathops tests use
> to control threading. They'll just ride on the global pool
> with all other tests now.
>
> This (temporarily?) removes the GPU multithreading feature
> from DM, which we don't use.
>
> On my desktop, DM runs a little faster (57s -> 55s) in
> Debug, and a lot faster in Release (36s -> 24s). The bots
> show speedups of similar proportions, cutting more than a
> minute off the N4/Release and Win7/Debug runtimes.
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6fR=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.orgTBR=bsalomon@google.com, bungeman@google.com, caryclark@google.com, mtklein@chromium.org, reed@google.com
NOTREECHECKS=true
NOTRY=true
BUG=skia:
Author: mtklein@google.com
Review URL: https://codereview.chromium.org/533393002
SkTaskGroup is like SkThreadPool except the threads stay in
one global pool. Each SkTaskGroup itself is tiny (4 bytes)
and its wait() method applies only to tasks add()ed to that
instance, not the whole thread pool.
This means we don't need to bring up new thread pools when
tests themselves want to use multithreading (e.g. pathops,
quilt). We just create a new SkTaskGroup and wait for that
to complete. This should be more efficient, and allow us
to expand where we use threads to really latency sensitive
places. E.g. we can probably now use these in nanobench
for CPU .skp rendering.
Now that all threads are sharing the same pool, I think we
can remove most of the custom mechanism pathops tests use
to control threading. They'll just ride on the global pool
with all other tests now.
This (temporarily?) removes the GPU multithreading feature
from DM, which we don't use.
On my desktop, DM runs a little faster (57s -> 55s) in
Debug, and a lot faster in Release (36s -> 24s). The bots
show speedups of similar proportions, cutting more than a
minute off the N4/Release and Win7/Debug runtimes.
BUG=skia:
R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, mtklein@google.com, reed@google.com
Author: mtklein@chromium.org
Review URL: https://codereview.chromium.org/531653002
