Commit Graph

158 Commits

Author SHA1 Message Date
mtklein
e71cd54ed4 SkTaskGroup::batch(fn, args, N)
Porting QuiltTask isn't important in itself; this is mostly an API feeler.

BUG=skia:

Review URL: https://codereview.chromium.org/689673003
2014-10-29 14:17:13 -07:00
halcanary
3dc5d70459 Use MacOS's CoreGraphics PDF Rasterizer in DM
BUG=3061

Review URL: https://codereview.chromium.org/650323004
2014-10-27 06:24:11 -07:00
bsalomon
06cddec857 Print GPU cache stats in nanobench/dm with veryVerbose
Review URL: https://codereview.chromium.org/680553002
2014-10-24 10:40:50 -07:00
halcanary
daf36c1524 Fix DMWriteTask to write PDF files correctly
Previously, it was not rewinding the asset.

Review URL: https://codereview.chromium.org/659793004
2014-10-17 14:36:10 -07:00
tfarina
cf9b87389f Clarify what DM means in the README file.
It took me a while to figure out what this acronym meant. ;)
Googling for it lead me to gyp/dm.gyp.

BUG=None
TEST=None
R=mtklein@google.com

Review URL: https://codereview.chromium.org/638083003
2014-10-09 09:00:30 -07:00
tfarina
6b87df2997 Fix usage of SK_BUILD_* defines.
Since we just 'define' them, but not attribute anything to them, like
'1' for example, cpp expands it to nothing and that breaks the "#if"
clauses.

To fix that, uses "#if defined(...)" which will correctly check if your
macro name was defined or not.

BUG=skia:2850
TEST=make most
R=robertphillips@google.com

Review URL: https://codereview.chromium.org/628763005
2014-10-06 10:46:51 -07:00
bungeman
d51ce44d18 Handle getMemoryBase returning NULL in WriteTask.
DM::WriteTask::fData was changed from a data to a stream in
"SkData to SkStreamAsset to avoid unneeded copying"
https://skia.googlesource.com/skia/+/a4c6094177ebde18c706cbcfbd2013d0a088e0ee
However, DM::WriteTask::draw was not updated to handle this,
resulting in segfaults when trying to write out PDF files.

Review URL: https://codereview.chromium.org/627473002
2014-10-02 13:39:00 -07:00
mtklein
a9ceaf5364 Don't test the old picture backend anymore.
This saves a bunch of CPU time in DM, and even better, lets us tear it down!

BUG=skia:
R=robertphillips@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/612603002
2014-09-29 08:44:46 -07:00
mtklein
e51ac563de Remove underscores from mode identifiers.
Underscore is used as a field separator sometimes when parsing the task
name into a list of config, mode, etc.  (This itself is dumb and TODO(mtklein): fix.)
Underscores in the field names will really mess that up, both in directories generated
from human-mode -w, and in the .json file.

BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/599503002
2014-09-23 09:20:14 -07:00
reed
4a8126e7f8 Introduce Props to surface (patchset #27 id:520001 of https://codereview.chromium.org/551463004/)"
This reverts commit 29c857d0f3.

TBR=

Author: reed@google.com

Review URL: https://codereview.chromium.org/588143004
2014-09-22 07:29:03 -07:00
reed
29c857d0f3 Revert of introduce Props to surface (patchset #27 id:520001 of https://codereview.chromium.org/551463004/)
Reason for revert:
Broke call site in WebKit

Original issue's description:
> introduce Props to surface (work in progress)
>
> BUG=skia:
>
> Committed: https://skia.googlesource.com/skia/+/3716fd067a5621bb94a6cb08d72afec8bf3aceda

R=robertphillips@google.com, bsalomon@google.com, jvanverth@google.com, bungeman@google.com, fmalita@google.com, vangelis@chromium.org, reed@google.com
TBR=bsalomon@google.com, bungeman@google.com, fmalita@google.com, jvanverth@google.com, reed@google.com, robertphillips@google.com, vangelis@chromium.org
NOTREECHECKS=true
NOTRY=true
BUG=skia:

Author: reed@chromium.org

Review URL: https://codereview.chromium.org/583773004
2014-09-21 10:25:07 -07:00
reed
3716fd067a introduce Props to surface (work in progress)
BUG=skia:
R=robertphillips@google.com, bsalomon@google.com, jvanverth@google.com, bungeman@google.com, fmalita@google.com, vangelis@chromium.org, reed@chromium.org

Author: reed@google.com

Review URL: https://codereview.chromium.org/551463004
2014-09-21 09:39:55 -07:00
mtklein
87e2437fe5 Add a "mode" tag to key in DM json output.
This lets us distinguish the original ("direct") runs from their replay modes.

There was a bit of a bug in here now fixed: we used the first entry in
fSuffixes as the config.  Actually, the last entry in suffixes is the
config.  This is moot when there's only one suffix (direct drawing), but
for mode drawing we were recording the mode as config!  Now it's correct.

Here's some example output where I rigged a bunch of modes to fail:

{
   "results" : [
      {
         "key" : {
            "config" : "565",
            "mode" : "default-nobbh",
            "name" : "xfermodes2"
         },
         "md5" : "2daf6f7e2b8e56543b92068a10d2179e",
         "options" : {
            "source_type" : "GM"
         }
      },
      {
         "key" : {
            "config" : "8888",
            "mode" : "default-nobbh",
            "name" : "xfermodes2"
         },
         "md5" : "490361e8a52800d29558bc23876da8c6",
         "options" : {
            "source_type" : "GM"
         }
      },
...
      {
         "key" : {
            "config" : "565",
            "mode" : "direct",
            "name" : "xfermodes2"
         },
         "md5" : "92a3801d5914d6c2662904a3bb50d2b9",
         "options" : {
            "source_type" : "GM"
         }
      },
...
      {
         "key" : {
            "config" : "8888",
            "mode" : "direct",
            "name" : "xfermodes2"
         },
         "md5" : "e7e8b3e9d31e601acaaff4633ed5f63a",
         "options" : {
            "source_type" : "GM"
         }
      },

BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/586533005
2014-09-19 10:35:07 -07:00
mtklein
53e0be6d2b DM: --gpu and --cpu should only control top-level tasks.
This fixes a bug where we run some Android bots with --nocpu, and the
current behavior disables the (CPU-bound) WriteTasks the GPU bound GM
runs spawn off.  The WriteTasks don't run and we end up with "null" in
our .json files.

Tested locally: out/Release/dm --nocpu -w /tmp/out; ls /tmp/out
  dm.json  gpu/

BUG=skia:2938
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/578033002
2014-09-17 12:26:18 -07:00
mtklein
0b36e6b65f Add --matrix to DM, to play around with and maybe use on a bot.
BUG=skia:
R=reed@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/563723005
2014-09-11 12:30:12 -07:00
mtklein
c54056c839 Back to hashing source content, not .png.
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/560453002
2014-09-09 08:42:04 -07:00
mtklein
ea65bfa8de Update DM JSON format.
Ex. dm --match patch -w bad --key arch x86 gpu nvidia model z620 --properties git_hash abcd build_number 20 ->

{
   "build_number" : "20",
   "git_hash" : "abcd",
   "key" : {
      "arch" : "x86",
      "gpu" : "nvidia",
      "model" : "z620"
   },
   "results" : [
      {
         "key" : {
            "config" : "565",
            "name" : "ninepatch-stretch"
         },
         "md5" : "f78cfafcbabaf815f3dfcf61fb59acc7",
         "options" : {
            "source_type" : "GM"
         }
      },
      {
         "key" : {
            "config" : "8888",
            "name" : "ninepatch-stretch"
         },
         "md5" : "3e8a42f35a1e76f00caa191e6310d789",
         "options" : {
            "source_type" : "GM"
         }
      },
...

This breaks -r, but that's okay.  Going to follow up this CL with one that removes that entirely.

BUG=skia:
R=stephana@google.com, jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/551873003
2014-09-09 07:59:46 -07:00
mtklein
197ceda929 Remove expectations / -r from DM entirely.
It's getting tricky to coordinate changes to output for bots with -r,
and -r is not widely used.  The suggested alternative is to run skdiff.

BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/553583004
2014-09-09 07:36:57 -07:00
mtklein
e2d4eb7072 Hash .pngs instead of SkBitmaps.
This has the nice property of being able to double-check hashes after the fact.

mtklein@mtklein ~/skia (hash-png)> md5sum bad/8888/3x3bitmaprect.png
deede70ab2f34067d461fb4a93332d4c  bad/8888/3x3bitmaprect.png

mtklein@mtklein ~/skia (hash-png)> grep 3x3bitmaprect_8888 bad/dm.json
   "3x3bitmaprect_8888" : "deede70ab2f34067d461fb4a93332d4c",

I have checked that no two premultiplied colors map to the same unpremultiplied
color (math nerds: unpremultiplication is injective), so a change in
premultiplied SkBitmap will always imply a change in the encoded
unpremultiplied .png.  This means, it's safe to hash .pngs; we won't miss
subtle changes.

BUG=skia:
R=jcgregorio@google.com, stephana@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/549203003
2014-09-08 12:42:23 -07:00
mtklein
858baf5b7d Add --nameByHash for the bots, and refactor hashing a bit.
No diff in dm.json output.

Here's what we get when --nameByHash is on:

mtklein@mtklein ~/skia (dm)> ls bad4/
0077fefedcee39feae9d12751853758b.png  431921de1607b4e1ae6864cc684d9b8e.png  8a3e17eba9302498700a703bb286d1ef.png  c6448cb266f5e0b8d02b512ad484a9ad.png
01b0dcd515e846ea3b7f3b4c68120943.png  4372eb0fce0b0bcf5a582c502f90ecef.png  8a6acdd96cf6915fa01a9cea6d6291b0.png  c6db4e2c9860b900130af429373eafaa.png
02974ab0efa7aa325b3bf22515b33899.png  43bddc2e255a3501ce2728544b1d409d.png  8aa8763d11afd397c2768e54d5599181.png  c716a9a53513a16e0572c67863e3be08.png
02b7b9e5e95e69f89b6cec9c4539d972.png  43cf7adda66b3719e4abd19e92dda55e.png  8ade6bb4c9e2244e0dbd9436cf6e2132.png  c854bb6dd105644a71d0219025409039.png
02d29dbfd29260f9318fcd6177c6ba7b.png  4423958139a2b64185583dacb7379b13.png  8b039171593685112a9454879f40a965.png  c863ac2394e519690c57e1392b14b19f.png
...

BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/550283002
2014-09-08 11:33:48 -07:00
mtklein
23c94f05ca Let .skps have Expectations (i.e. work with -r) too.
BUG=skia:
R=jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/549183002
2014-09-08 09:12:28 -07:00
mtklein
1d0f1642e8 Start to rework DM JSON handling.
DM's striking off into its own JSON world.  This gets strawman implementations
in place for writing and reading a JSON file mapping test name to hashes.

For what it's worth, I basically want to change _all_ these pieces,
  - MD5 is slow and we can replace it with something faster,
  - JSON schema needs room to grow more data,
  - it'd be nice to hash once instead of twice when reading and writing,
  - this code wants lots of refactoring,
but this gives us a starting platform to work on these bits at our leisure.

E.x. file for now:

mtklein@mtklein ~/skia (dm)> cat good/dm.json
{
   "3x3bitmaprect_565" : "fc70d985fbfbe70e3a3c9dc626d4f5bc",
   "3x3bitmaprect_8888" : "df1591dde35907399734ea19feb76663",
   "3x3bitmaprect_gpu" : "df1591dde35907399734ea19feb76663",
   "aaclip_565" : "1862798689b838a7ab0dc0652b9ace3a",
   "aaclip_8888" : "47bb314329f0ce243f1d83fd583decb7",
   "aaclip_gpu" : "75f72412d0ef4815770202d297246e7d",
...

BUG=skia:
R=jcgregorio@google.com, stephana@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/546873002
2014-09-08 08:05:18 -07:00
robertphillips
c5ba71d2e5 Change SkPicture::draw to playback
R=reed@google.com

Author: robertphillips@google.com

Review URL: https://codereview.chromium.org/540963002
2014-09-04 08:42:50 -07:00
mtklein
406654be7a 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/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f

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
2014-09-03 15:34:37 -07:00
mtklein
2460bbdfbb Revert of SkThreadPool ~~> SkTaskGroup (patchset #4 id:60001 of 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/+/9c7207b5dc71dc5a96a2eb107d401133333d5b6f

R=caryclark@google.com, bsalomon@google.com, bungeman@google.com, reed@google.com, mtklein@chromium.org
TBR=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
2014-09-03 14:17:48 -07:00
mtklein
9c7207b5dc 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:
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
2014-09-03 14:06:48 -07:00
robertphillips
a8d7f0b13c Try out scalar picture sizes
This paves the way for removing the 'fTile' parameter from SkPictureShader (although that should be a different CL). If we like this we could also move to providing an entire cull SkRect.

R=reed@google.com, mtklein@google.com, fmalita@google.com, fmalita@chromium.org

Author: robertphillips@google.com

Review URL: https://codereview.chromium.org/513983002
2014-08-29 08:03:56 -07:00
mtklein
2a65a238b0 Remove SkQuadTree.
We're not testing it to the same degree we do RTree and TileGrid.  Any changes
we'll make to BBH APIs become 33% easier without it.  If find we want it again,
we can always resurrect it.

BUG=skia:1021,skia:2834
R=robertphillips@google.com, mtklein@google.com
TBR=reed

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/500373005
2014-08-26 14:07:04 -07:00
halcanary
a4c6094177 SkData to SkStreamAsset to avoid unneeded copying
R=mtklein@google.com

Author: halcanary@google.com

Review URL: https://codereview.chromium.org/502193002
2014-08-26 10:38:07 -07:00
mtklein
c92e550d36 Install a hook to swap between SkPicture backends with a single define.
BUG=skia:
R=robertphillips@google.com, reed@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/492023002
2014-08-21 13:07:27 -07:00
mtklein
afb4379dbc Print max RSS in GM and nanobench too.
Everyone used MB, so update the API to just return that.

BUG=skia:
R=halcanary@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/483323002
2014-08-19 15:55:55 -07:00
mtklein
0ed4e863c0 Stop sorting the results of SkBBH::search().
We only seem to need to sort with SkQuadTree, which is not actively used by
client code.  So it's really just wasted work.  SkQuadTree is interesting, but
I'd rather disable it than slow down the production code path.

BUG=skia:2834
R=robertphillips@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/471063004
2014-08-18 08:23:19 -07:00
mtklein
60c7707958 Guard ANGLE and MESA instead of defining them as native when unsupported.
Since we've added "angle" to the default list of configs we've been running
kNative_GLContextType tests twice in DM, once for the real native, once for
angle.  This pointlessly doubles the GPU critical path in DM.  Whoops.

NOTREECHECKS=true

BUG=skia:
R=bsalomon@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/471063002
2014-08-14 10:36:55 -07:00
halcanary
59598b0a9b DM: Replace --pathOpsVerbose with --veryVerbose
R=caryclark@google.com, mtklein@google.com

Author: halcanary@google.com

Review URL: https://codereview.chromium.org/468963002
2014-08-13 10:30:57 -07:00
mtklein
03bde3e6fa SkTileGrid: store insertion order, return results sorted by that.
This removes the need to assume the void* are SkPictureStateTree::Data*.

BUG=skia:
R=robertphillips@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/466503002
2014-08-12 07:01:25 -07:00
halcanary
0d154eeaeb Process Statistics header, add max RSS to render_pdfs
Committed: https://skia.googlesource.com/skia/+/6274baae7fe82ce6481da367687aa6168356e1e1

R=mtklein@google.com

Author: halcanary@google.com

Review URL: https://codereview.chromium.org/448993003
2014-08-11 11:33:51 -07:00
mtklein
5ad6ee1b2c Plumbing for using a BBH in SkRecordDraw.
For now this only creates a degenerate bounding box hierarchy where all ops
just have maximal bounds.  I will flesh out FillBounds in future CL(s).

Not quite sure why QuadTree and TileGrid aren't drawing right---haven't even
looked at the diffs yet---so I've disabled those test modes for now.  RTree
seems fine, so that'll at least get us coverage for all this new plumbing.

BUG=skia:
R=robertphillips@google.com, mtklein@google.com, reed@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/454123003
2014-08-11 08:08:43 -07:00
mtklein
b511042bb0 Fix iOS build by centralizing --writePath.
CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Debug-iOS-Trybot

BUG=skia:
R=mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/452633002
2014-08-07 15:20:02 -07:00
mtklein
72ebb9f1dc DM: conserve memory when using --skps
- limit to maximum 1000x1000 viewport like in bench_pictures and nanobench
 - use lazy bitmap decoding when reading the pictures from disk

BUG=skia:
R=reed@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/448263002
2014-08-07 14:27:03 -07:00
bungeman
619e07656d Revert of Process Statistics header, add max RSS to render_pdfs (https://codereview.chromium.org/448993003/)
Reason for revert:
Reverting due to breaking iOS bots.

Original issue's description:
> Process Statistics header, add max RSS to render_pdfs
>
> Committed: https://skia.googlesource.com/skia/+/6274baae7fe82ce6481da367687aa6168356e1e1

R=mtklein@google.com, halcanary@google.com
TBR=halcanary@google.com, mtklein@google.com
NOTREECHECKS=true
NOTRY=true

Author: bungeman@google.com

Review URL: https://codereview.chromium.org/448243003
2014-08-07 13:27:18 -07:00
halcanary
6274baae7f Process Statistics header, add max RSS to render_pdfs
R=mtklein@google.com

Author: halcanary@google.com

Review URL: https://codereview.chromium.org/448993003
2014-08-07 13:13:54 -07:00
mtklein
bcd278dfd2 DM: expand peak RAM usage to Mac and Android too.
BUG=skia:

NOTREECHECKS=true
R=halcanary@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/445963002
2014-08-06 07:46:30 -07:00
mtklein
36ea6c81c2 For some reason, starting tests before gms makes DM run much faster.
Must be getting the path ops tests going early helps?

On my desktop,
Release: 50s -> 24s
Debug: 62s -> 40s

BUG=skia:
R=bsalomon@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/435423003
2014-08-05 07:19:46 -07:00
mtklein
4e212e8da7 Print max memory usage on Linux.
This is meant to help debug http://skbug.com/2793

BUG=skia:2793
R=halcanary@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/433403005
2014-08-04 14:10:19 -07:00
mtklein
92007583e4 SKPs-as-benches in nanobench
This is meant to replace bench_pictures.

CQ_EXTRA_TRYBOTS=tryserver.skia:Build-Mac10.7-Clang-Arm7-Release-iOS-Trybot

BUG=skia:
R=bsalomon@google.com, jcgregorio@google.com, mtklein@google.com

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/425393004
2014-08-01 07:46:53 -07:00
Cary Clark
992c7b03ef Add standard fonts to all GMs.
Allow GM results to be compared across machines and platforms by
standardizing the fonts used by all tests.

This adds runtime flags to DM to use either the system font context (the
default), the fonts in the resources directory ( --resourceFonts ) or a set
of canonical paths generated from the fonts ( --portableFonts ).

This CL should leave the current DM results unchanged by default.

If the portable font data or resource font is missing when DM is run, it
falls back to using the system font context.

The create_test_font tool generates the paths and metrics read by DM
with the --portableFonts flag set, and generates the font substitution
tables read by DM with the --resourceFonts flag set.

If DM is run in SkDebug mode with the --reportUsedChars flag set, it
generates the corresponding data compiled into the create_test_font tool.

All GM tests set their typeface information by calling either

  sk_tool_utils::set_portable_typeface or
  sk_tool_utils::portable_typeface .

(The former takes the paint, the latter returns a SkTypeface.) These calls
can be removed in the future when the Font Manager can be superceded.

BUG=skia:2687
R=mtklein@google.com

Review URL: https://codereview.chromium.org/407183003
2014-07-31 08:58:44 -04:00
tfarina
a8e2e1504b Cleanup: Rename SkOSPath functions.
Mostly for brevity and matches better with Python:

Python           | Old C++                 | New C++
os.path.join     | SkOSPath::SkPathJoin    | SkOSPath::Join
os.path.basename | SkOSPath::SkBasename    | SkOSPath::Basename

BUG=None
TEST=make all
R=mtklein@google.com, bsalomon@google.com

Author: tfarina@chromium.org

Review URL: https://codereview.chromium.org/428443002
2014-07-28 19:26:58 -07:00
bsalomon
2354f8432a Test abandoning GL context in dm/nanobench.
Rename GrContext::contextDestroyed to GrContext::abandonContext.

Remove GrContext::resetContext.

R=robertphillips@google.com

Author: bsalomon@google.com

Review URL: https://codereview.chromium.org/422903002
2014-07-28 13:48:36 -07:00
halcanary
a98683bc50 dm prints out number of matching skp files
R=bungeman@google.com, mtklein@google.com

Author: halcanary@google.com

Review URL: https://codereview.chromium.org/421713002
2014-07-28 07:21:24 -07:00
halcanary
048f422ec6 Fix crash in DM/SKPTask
R=bungeman@google.com

Author: halcanary@google.com

Review URL: https://codereview.chromium.org/416333007
2014-07-25 14:17:35 -07:00