Commit Graph

13 Commits

Author SHA1 Message Date
Mike Klein
e15a7b528e ok, most features can be vias
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>
2017-03-31 03:03:18 +00:00
Mike Klein
200f6da4cd ok, unify failure and crash logging
Just as deferred and locked crash logging makes crashes easier to read,
so does deferred and locked failure logging make failures easier to read.

Change-Id: I71578d61b0056f8d7e692149762def1f155c0387
Reviewed-on: https://skia-review.googlesource.com/10280
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-28 14:11:38 +00:00
Mike Klein
d63442d87c ok: add basic unit test support
Plenty TODO remaining.

This can actually kind of run without a test reporter or GrContext:
    $ out/ok test
    784 ok, 56 crashed
    ... lots of stack traces ...
Most tests don't use the reporter unless they're going to fail.

Change-Id: I7333e2c63ade5e671ebf60022d19390f1fc1c93a
Reviewed-on: https://skia-review.googlesource.com/10201
Commit-Queue: Mike Klein <mtklein@chromium.org>
Reviewed-by: Brian Salomon <bsalomon@google.com>
2017-03-27 19:33:31 +00:00
Mike Klein
88f9c1eff9 ok: alias 565 -> sw:ct=565
This is mostly a demo, and to make sure it's easy.
If I'm thinking right, other non-ct options should Just Work.

Change-Id: I295db0fa04921ccdd766e1870e367594ca802462
Reviewed-on: https://skia-review.googlesource.com/10190
Reviewed-by: Brian Salomon <bsalomon@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-27 17:24:35 +00:00
Mike Klein
59eed0db99 ok: handle concurrent crashes better
lockf() is a simple way to prevent interlaced stack traces when there
are concurrent crashes.  After a crashing process rethrows its signal
and dies for real, the OS unlocks the file for other processes.

I tested this by making SkCanvas::drawRRect() crash on Linux:
20-odd GM crashes with interlaced stack traces before, none after.

Change-Id: I99930756b8c85c552eef7c3a77778e4c00d34c42
Reviewed-on: https://skia-review.googlesource.com/10177
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-27 14:54:51 +00:00
Mike Klein
0222e709a3 ok: refactor Src/Dst interactions
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>
2017-03-25 20:43:01 +00:00
Mike Klein
f5d1a5567e ok: basic Vias
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>
2017-03-25 17:32:20 +00:00
Mike Klein
7ac04838c5 Spin off non-core parts of ok into their own files.
Now ok.cpp handles only the high level coordination of Srcs and Dsts,
without having to know or care what they are.

Some minor refactoring to things like Options.

Change-Id: I02df890b26d6d069e980a125b6a1ce1a7067b900
Reviewed-on: https://skia-review.googlesource.com/10173
Reviewed-by: Mike Klein <mtklein@chromium.org>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-25 16:13:20 +00:00
Mike Klein
51fe971046 ok: introduce the idea of Dsts
Change-Id: I47ac01f0c2c0f2f7b925de09c18d3c8265398c8a
Reviewed-on: https://skia-review.googlesource.com/10117
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-24 21:49:53 +00:00
Mike Klein
adf7b330bd ok: fix an assert from unbalanced save/restores
The 'dont_clip_to_layer' GM does not balance its layers.  It calls
saveLayer() 3x but restore() only 2x.  This may be a bug in the GM
itself, but I'm not sure so I haven't changed it here.

If ok is writing .pngs, the surface passes ownership of its buffer to an
image snapshot, simply marking it as immutable.  Then, when the surface
is destroyed later, it destroys its inner canvas, which restores its
save stack to zero, actually doing some drawing in the case of
unbalanced saveLayer()s.  We then call notifyPixelsChanged() and hit an
assert saying "you just wrote some pixels but this buffer was marked
immutable."

DM doesn't show this problem because it's doesn't really use surfaces
and images, just bitmaps.  There's no ownership handoff and nothing is
ever immutable, so the condition triggering the assert never comes up.

I'm not really sure where we want to say is the bug:
  - SkCanvas can draw in its destructor?
  - SkSurface doesn't restore to zero before snapping an image?
  - that dont_clip_to_layer should call restore three times?

In any case, this guards against it in ok.

I was using this as a convenient crash to help figure out how to best
save and print stack traces, but now that I've got that worked out we
might as well fix this.

Change-Id: Id6d397f534dd1b50219e0d3078c989a4910883a6
Reviewed-on: https://skia-review.googlesource.com/10140
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-24 15:58:50 +00:00
Mike Klein
61e990297a ok: basic crash handling and stack trace dumps
This seems to work pretty nicely for each engine in the expected case of
few crashes.  The serial and thread engines just dump the first crash
stack to stderr before dying, while the fork engine saves all crashes to
a temporary file, then prints that to stderr once everything's finished.

I'm not sold on this TLS solution as being the best way to know what
was running when we crashed, but it's better than printing nothing.

Change-Id: I0aca66529301b1ad9bd51ec728848817586c606d
Reviewed-on: https://skia-review.googlesource.com/10102
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-24 15:55:50 +00:00
Mike Klein
9827256c8a Improve TaskEngine::wait_one().
This runs much faster.  Very good idea.

Change-Id: I088aa9588c069a17e4745be55c2397114ee8a2bc
Reviewed-on: https://skia-review.googlesource.com/10053
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-23 20:41:20 +00:00
Mike Klein
06432b26c6 ok
Change-Id: I9d01656a9d9b7aa3ab352dd4c168b26da620a903
Reviewed-on: https://skia-review.googlesource.com/9978
Reviewed-by: Herb Derby <herb@google.com>
Commit-Queue: Mike Klein <mtklein@chromium.org>
2017-03-23 18:04:36 +00:00