SkRecord strawman

SkRecord strawman

Record performance as measured by bench_record (out/Release/bench_record --skr) improves by at least 1.9x, at most 6.7x, arithmetic mean 2.6x, geometric mean 3.0x.  So, good.

Correctness as measured by DM (out/Debug/dm --skr) is ~ok.  One GM (shadertext2) fails because we're assuming all paint effects are immutable, but SkShaders are still mutable.

To do after this CL:
  - measure playback speed
  - catch up feature-wise to SkPicture
  - match today's playback speed


BUG=skia:

Committed: http://code.google.com/p/skia/source/detail?r=14010

[mtklein, 2014-03-20 16:30:03]

FYI for now.

[mtklein, 2014-03-20 19:02:41]

On 2014/03/20 16:30:03, mtklein wrote:
> FYI for now.

Bitmap mutability was indeed the big remaining issue.  That's nearly fixed now;
I still have some corner cases of deep copying bitmaps to sort out next week. 
Whether or not we care about handling mutable bitmaps efficiently is still TBD. 
I'd say we care in proportion to how often they're passed to Skia by Chrome,
which I also intend to look at next week.

There's now just 1 failing GM, shadertext2.  A quick look at the images and GM
code leads me to believe the problem is just that SkShaders are still stateful.

[mtklein_C, 2014-03-24 22:33:48]

OK, I think I'm happy enough with this now to land a first draft.  It's hidden
off in its own src/record directory and gyp target, only hooked into DM and
bench_record for now.

Reviewers, please review. CC'ers, please feel free to promote yourselves back up
to reviewer if you'd like.

[robertphillips, 2014-03-26 11:52:19]

It seems like this has a big overlap with the SkDrawCommand/SkDebugCanvas use
case.

[mtklein, 2014-03-26 12:07:00]

On 2014/03/26 11:52:19, robertphillips wrote:
> It seems like this has a big overlap with the SkDrawCommand/SkDebugCanvas use
> case.

Hadn't thought of that until you mention it, but after a quick look I
tentatively agree.  I think SkRecord's probably structured suitably to serve as
the backbone of SkDebugCanvas.  I'd want to get a demo of that working before
committing to replacing SkDrawCommand, though, if only to see how we'd need to
change SkRecord to accomodate SkDebugCanvas.  Not saying we should never do it,
but I want to make sure we get the production use cases solid first before we
look at adding whizbells for debugging.

[mtklein, 2014-04-01 15:28:03]

Seeing little activity here, I'm going to plow ahead with this so I can keep
hacking.

lgtm

[mtklein, 2014-04-01 15:28:13]

The CQ bit was checked by mtklein@google.com

[commit-bot: I haz the power, 2014-04-01 15:28:18]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@chromium.org/206313003/520001

[commit-bot: I haz the power, 2014-04-01 16:24:13]

Change committed as 14010

[Dominik Grewe, 2014-04-01 18:05:19]

On 2014/04/01 16:24:13, I haz the power (commit-bot) wrote:
> Change committed as 14010

Did you manage to benchmark playback? Do you see any regressions due to not
caching the font metrics?

[mtklein, 2014-04-02 14:48:11]

On 2014/04/01 18:05:19, Dominik Grewe wrote:
> On 2014/04/01 16:24:13, I haz the power (commit-bot) wrote:
> > Change committed as 14010
> 
> Did you manage to benchmark playback? Do you see any regressions due to not
> caching the font metrics?

It performs suspiciously well.  I don't trust the system enough to post numbers.

I think what's going on is I'm unintentionally getting the combined benefits of
SkPicture and SkRecord because of how I'm bootstrapping:
  - We get Chromium to record us an SkPicture from a web archive
  - SkPicture does some optimization during its record phase, rewriting raw
SkCanvas calls into faster ones, or including recording data to make its
playback faster
  - We serialize that to disk
  - We deserialize that from disk
  - SkPicture plays it back into an SkRecord, taking advantage of optimizations
done in record phase
  - The resulting SkRecord mirrors the optimized SkPicture, logically equivalent
to but not literally equal to Blink's SkCanvas calls

I don't have a way yet to create an SkRecord from a web archive that doesn't
first go through SkPicture.

Comparison of record performance should still be fair: that's comparing the same
pre-optimized disk SKP continuously re-recorded either into an SkPicture or an
SkRecord; the only variable there is the receiving canvas in the loop.

[Sami, 2014-04-02 16:29:30]

On 2014/04/02 14:48:11, mtklein wrote:
> I don't have a way yet to create an SkRecord from a web archive that doesn't
> first go through SkPicture.

Would it be worth throwing together a patch to use SkRecord in Chrome? That way
we could test this with rasterize_and_record.

[mtklein, 2014-04-02 16:50:01]

On 2014/04/02 16:29:30, Sami wrote:
> On 2014/04/02 14:48:11, mtklein wrote:
> > I don't have a way yet to create an SkRecord from a web archive that doesn't
> > first go through SkPicture.
> 
> Would it be worth throwing together a patch to use SkRecord in Chrome? That
way
> we could test this with rasterize_and_record.

Yup, that's my thinking too.

[nduca, 2014-04-02 18:48:42]

sounds like we should filez a boog

[mtklein, 2014-04-02 19:39:35]

On 2014/04/02 18:48:42, nduca wrote:
> sounds like we should filez a boog

I just made https://code.google.com/p/skia/issues/detail?id=2378