No deduping dictionaries for matrices and regions.

No deduping dictionaries for matrices and regions.

There's little benefit to deduping matrices and regions: they're infrequently
used, and doubly infrequently reused.  Their use-weighted byte cost is tiny.

There is some downside to deduping matrices and regions.  Even when they're not
used, we prepare dictionaries for deduping them for every picture.  Each of
these dictionaries costs 160 bytes, so two unused dictionaries make a big chunk
of the ~1100 bytes it takes to allocate an SkPictureRecord. (~330 come from
parent class SkCanvas, 768 from SkPictureRecord itself, here reduced to 448).

One side benefit of not deduping these guys is that the change weighs -140 lines of code.

It may go without saying, but this breaks the picture format.

Testing: out/Debug/tests && out/Debug/dm  (which runs all picture modes by default)

BUG=skia:1850
Committed: http://code.google.com/p/skia/source/detail?r=13149

[reed1, 2014-01-21 18:38:59]

bump version in SkPicture.h ?

lgtm

[mtklein, 2014-01-21 18:58:51]

Bumped to v19.

Robert, can you take a look to see if all the picture version TODOs look to be
done correctly?  (PS 2)

[mtklein, 2014-01-21 20:00:22]

In case anyone's holding their breath, I'm going to delay submitting this and
its new SKPs until tomorrow.  Going to go WFH now to avoid the snow.

[mtklein, 2014-01-23 14:49:40]

On 2014/01/21 20:00:22, mtklein wrote:
> In case anyone's holding their breath, I'm going to delay submitting this and
> its new SKPs until tomorrow.  Going to go WFH now to avoid the snow.

OK, ready to roll.  I'm going to submit this and upload the new SKPs.  There may
be some spurious failures if old code reads the new SKPs.  I've got them backed
up in case we need to roll back.

[commit-bot: I haz the power, 2014-01-23 14:50:08]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/mtklein@google.com/143883006/50001

[rmistry, 2014-01-23 14:50:57]

On 2014/01/23 14:49:40, mtklein wrote:
> On 2014/01/21 20:00:22, mtklein wrote:
> > In case anyone's holding their breath, I'm going to delay submitting this
and
> > its new SKPs until tomorrow.  Going to go WFH now to avoid the snow.
> 
> OK, ready to roll.  I'm going to submit this and upload the new SKPs.  There
may
> be some spurious failures if old code reads the new SKPs.  I've got them
backed
> up in case we need to roll back.

I would:
1) Close the tree.
2) Upload the new SKPs and update the TIMESTAMP file.
3) Submit this CL.

[mtklein, 2014-01-23 14:53:38]

On 2014/01/23 14:50:57, rmistry wrote:
> On 2014/01/23 14:49:40, mtklein wrote:
> > On 2014/01/21 20:00:22, mtklein wrote:
> > > In case anyone's holding their breath, I'm going to delay submitting this
> and
> > > its new SKPs until tomorrow.  Going to go WFH now to avoid the snow.
> > 
> > OK, ready to roll.  I'm going to submit this and upload the new SKPs.  There
> may
> > be some spurious failures if old code reads the new SKPs.  I've got them
> backed
> > up in case we need to roll back.
> 
> I would:
> 1) Close the tree.
> 2) Upload the new SKPs and update the TIMESTAMP file.
> 3) Submit this CL.

Why not

1) Upload new SKPs
2) Submit this CL.
3) Upload new TIMESTAMP.

?

[rmistry, 2014-01-23 14:56:59]

On 2014/01/23 14:53:38, mtklein wrote:
> On 2014/01/23 14:50:57, rmistry wrote:
> > On 2014/01/23 14:49:40, mtklein wrote:
> > > On 2014/01/21 20:00:22, mtklein wrote:
> > > > In case anyone's holding their breath, I'm going to delay submitting
this
> > and
> > > > its new SKPs until tomorrow.  Going to go WFH now to avoid the snow.
> > > 
> > > OK, ready to roll.  I'm going to submit this and upload the new SKPs. 
There
> > may
> > > be some spurious failures if old code reads the new SKPs.  I've got them
> > backed
> > > up in case we need to roll back.
> > 
> > I would:
> > 1) Close the tree.
> > 2) Upload the new SKPs and update the TIMESTAMP file.
> > 3) Submit this CL.
> 
> Why not
> 
> 1) Upload new SKPs
> 2) Submit this CL.
> 3) Upload new TIMESTAMP.
> 
> ?

Your steps will work if you do 2) and 3) very quickly together.

[mtklein, 2014-01-23 14:57:44]

On 2014/01/23 14:56:59, rmistry wrote:
> On 2014/01/23 14:53:38, mtklein wrote:
> > On 2014/01/23 14:50:57, rmistry wrote:
> > > On 2014/01/23 14:49:40, mtklein wrote:
> > > > On 2014/01/21 20:00:22, mtklein wrote:
> > > > > In case anyone's holding their breath, I'm going to delay submitting
> this
> > > and
> > > > > its new SKPs until tomorrow.  Going to go WFH now to avoid the snow.
> > > > 
> > > > OK, ready to roll.  I'm going to submit this and upload the new SKPs. 
> There
> > > may
> > > > be some spurious failures if old code reads the new SKPs.  I've got them
> > > backed
> > > > up in case we need to roll back.
> > > 
> > > I would:
> > > 1) Close the tree.
> > > 2) Upload the new SKPs and update the TIMESTAMP file.
> > > 3) Submit this CL.
> > 
> > Why not
> > 
> > 1) Upload new SKPs
> > 2) Submit this CL.
> > 3) Upload new TIMESTAMP.
> > 
> > ?
> 
> Your steps will work if you do 2) and 3) very quickly together.

I'm feeling lucky.

[commit-bot: I haz the power, 2014-01-23 15:16:11]

Change committed as 13149

[robertphillips, 2014-01-31 19:22:39]

So I am (or was) using the matrix and region dictionaries extensively in this CL
(https://codereview.chromium.org/139093003/). I wasn't relying on the de-duping
(since I am/was holding on to the id) as much as being able to concisely refer
to matrices and regions over and over again.

[mtklein, 2014-01-31 19:32:35]

On 2014/01/31 19:22:39, robertphillips wrote:
> So I am (or was) using the matrix and region dictionaries extensively in this
CL
> (https://codereview.chromium.org/139093003/). I wasn't relying on the
de-duping
> (since I am/was holding on to the id) as much as being able to concisely refer
> to matrices and regions over and over again.

If you're not deduping, can you just push onto an SkTDArray and hold the index? 
or ID them by the byte offset they're written to in the op stream?