Add a real implementation for gm_knowledge.h This depends on
the presence of files in the form $GMK_DIR/foo/{max,min}.png
The implementation also writes out failures in a report directory.
Add a utility: experimental/make_gmkb which is a stand-alone
go executable that generates the foo/{max,min}.png data.
tools/skqp/README.md has instructions on running SkQP.
Also: add SkFontMgrPriv.h
Change-Id: Ibe1e9a7e7de143d14eee3877f5f2d2d8713f7f49
Reviewed-on: https://skia-review.googlesource.com/65380
Reviewed-by: Yuqian Li <liyuqian@google.com>
Commit-Queue: Hal Canary <halcanary@google.com>
Change-Id: I4dc745479ceb1d5ca1ddb4a0904f342576e4562c
Reviewed-on: https://skia-review.googlesource.com/71240
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Hal Canary <halcanary@google.com>
The bots will still use DM, but the multiprocess architecture of ok
makes it easier to isolate and debug crashes, assertions, and unit
test failures.
Usage:
$ ninja -C out ok
$ out/ok test portable_fonts
...
935 ok, 4 failed, 5 crashed
...
Change-Id: I6bbd0ffc02d19bb5907c71eaebe30ac3646a80a6
Reviewed-on: https://skia-review.googlesource.com/68201
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: Ib7f855c833c8e73f448de7c8a75f59b1a0880874
Reviewed-on: https://skia-review.googlesource.com/53600
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This is the same sort of thing as DM's serialize via.
It draws into a picture, serializes that, deserializes that,
and then draws that picture into the destination.
Change-Id: Ib58748786bc01fd8a0cb9355a2fd334311c361bf
Reviewed-on: https://skia-review.googlesource.com/49902
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I562d438bd65e9fd900cfc6831f971b4af25c8ae6
Reviewed-on: https://skia-review.googlesource.com/26361
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This doesn't do anything in the default process-per-task mode, because
those child tasks exit using _exit(), which doesn't trigger the event
tracer destructor to flush.
I don't remember exactly why I exit with _exit(), so I'm going to have
to follow up on that. But written this way as I think I'm at least
initializing the tracing in the right place for each process for the
future.
In threaded (-j -1) and serial (-j 0) modes, everything seems to work
great.
I'm also thinking I might add a tracer like the SkDebugf tracer but
using ok_log(), which handles interlaced logging from concurrent tasks
better than vanilla SkDebugf.
Example:
ninja -C out ok; and out/ok gm 8888 filter:search=fontmgr_bounds trace -j -1
Change-Id: Ia3cdad930ce65e6fd12fa74f3fb00894e35138d3
Reviewed-on: https://skia-review.googlesource.com/26350
Reviewed-by: Brian Osman <brianosman@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I6feb4924ab67e1da08f923315ef6d3a580881b23
Reviewed-on: https://skia-review.googlesource.com/26340
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Just like the time via, but instead of printing how long the thing took
to run it prints how much memory was used by the process at peak.
When ok runs in (default) process-per-task mode, this is quite handy.
Change-Id: I331d446e39363a44c545278d7153fa7548e2add0
Reviewed-on: https://skia-review.googlesource.com/20261
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I2b26ccd017d9e66ced41a1af04929e2d83a5a2d5
Reviewed-on: https://skia-review.googlesource.com/16343
Reviewed-by: Mike Klein <mtklein@chromium.org>
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Change-Id: I3d25a2aa9ae6dacb52779142cea062c7d9df40f5
Reviewed-on: https://skia-review.googlesource.com/16238
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
I can't tell you how excited I am to turn down the libpng settings...
anything that saves me a few seconds is a nice quality of life win.
This CL makes ok run in about half the time when producing .pngs.
Profile running `ok gm srgb png` before:
10.59 s 16.5% 10.59 s longest_match
8.98 s 14.0% 8.98 s png_setup_paeth_row
8.93 s 13.9% 8.93 s skia_png_write_find_filter
7.75 s 12.1% 7.75 s deflate_slow
4.63 s 7.2% 4.63 s std::wait_until(...) const
959.00 ms 1.5% 959.00 ms SkPathRef::validate() const
935.00 ms 1.4% 935.00 ms sk_to_srgb_hsw
...
After:
2.35 s 8.7% 2.35 s std::wait_until(...) const
1.70 s 6.2% 1.70 s longest_match
1.19 s 4.4% 1.19 s deflate_fast
931.00 ms 3.4% 931.00 ms SkPathRef::validate() const
898.00 ms 3.3% 898.00 ms sk_to_srgb_hsw
...
Change-Id: I425c30b2ecd97a0e4a4392779de6301db473ee47
Reviewed-on: https://skia-review.googlesource.com/15547
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Matt Sarett <msarett@google.com>
SkLights.h pulls in a bunch of other headers and is not needed (fwdecl
works fine).
Change-Id: I3ed97cd7861e51dcb7cfa7950a97b420dbc6fbfb
TBR=reed@google.com
Reviewed-on: https://skia-review.googlesource.com/15143
Commit-Queue: Florin Malita <fmalita@chromium.org>
Reviewed-by: Florin Malita <fmalita@chromium.org>
This reverts commit 9ff301bf91.
Reason for revert: need to update G3, Flutter.
Original change's description:
> Remove SkLights include from SkCanvas.h
>
> SkLights.h pulls in a bunch of other headers and is not needed (fwdecl
> works fine).
>
> Change-Id: Id2d7176eb3bf4609f72f46d513eebf59318f542f
> Reviewed-on: https://skia-review.googlesource.com/14904
> Reviewed-by: Mike Reed <reed@google.com>
> Commit-Queue: Florin Malita <fmalita@chromium.org>
>
TBR=mtklein@google.com,fmalita@chromium.org,reed@google.com
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
Change-Id: I4799ad5b31aaeaf529c8b912bbe09aa8869a5e6c
Reviewed-on: https://skia-review.googlesource.com/15107
Reviewed-by: Florin Malita <fmalita@chromium.org>
Commit-Queue: Florin Malita <fmalita@chromium.org>
SkLights.h pulls in a bunch of other headers and is not needed (fwdecl
works fine).
Change-Id: Id2d7176eb3bf4609f72f46d513eebf59318f542f
Reviewed-on: https://skia-review.googlesource.com/14904
Reviewed-by: Mike Reed <reed@google.com>
Commit-Queue: Florin Malita <fmalita@chromium.org>
This refactors most features out of ok's core into vias:
-w --> a .png dumping via, "png", opening the door to other types
-m/-s --> a filtering via "filter"
Everything now can print a brief help message too.
Change-Id: I9e653aab98fd57182a6d458c7a80052130980284
Reviewed-on: https://skia-review.googlesource.com/10509
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
This makes everything a lot more like DM, for the same reason:
it's the best way to make Vias work.
Instead of exposing a canvas, Dsts take a Src to draw. Vias still are
Dsts that wrap Dsts. They do their internal work in draw() then pass a
proxy Src encapsulating that work to the next Dst's draw().
A little refactoring in ok.cpp allows arbitrary chains of Vias.
I removed the guarantee that Src methods are called in strict order.
It's easy enough to make each Src initialize itself as needed.
I moved the .png encoding back to ok.cpp. It seemed weird for Dsts to
have to think about files and paths. One day Dst will want a data()
method for non-image output (.pdf, .skp), and then we'll want ok.cpp to
be the one to coordinate what to write where.
Change-Id: Id4a3674b2d05aef2b5f10e0077df0a8407c07b61
Reviewed-on: https://skia-review.googlesource.com/10175
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
Not sure if these simple Src/Dst interfaces will last.
Vias are a little tricky, and some may be impossible.
Change-Id: I42d19b1ee74b51a830bb781f25a888c0b32ba98c
Reviewed-on: https://skia-review.googlesource.com/10174
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
