XPS ttc handling.

XPS ttc handling.

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

[bungeman-skia, 2013-05-06 17:51:25]

Now that the XPS files can be written out correctly by GM, XPS makes an
interesting use case for testing our new-found ability to know which font in a
ttc to use. This change reduces the size of the fontmgr_iter XPS file produced
on my machine from ~270MB to ~2.7MB.

One issue found during this process is that it would be nice to support -1 as
the index of non-indexed fonts, so that an index >= 0 can be used directly as an
index instead of needing to look inside the font to determine if a '0' is an
index or not. XPS uses -1 this way, DirectWrite uses an unsigned and returns a
0. This is somewhat awkward.

[reed1, 2013-05-06 18:09:58]

https://codereview.chromium.org/14873006/diff/11002/include/core/SkTemplates.h
File include/core/SkTemplates.h (right):

https://codereview.chromium.org/14873006/diff/11002/include/core/SkTemplates....
include/core/SkTemplates.h:112: T* set(T* ptr) {
Do we have this pattern (where we return the old as we accept a new) in other
helpers? It is certainly different from reset(), which always disposes of the
old while accepting the new...

[bungeman-skia, 2013-05-06 20:48:45]

An attempt to avoid the odd 'set' method.

https://codereview.chromium.org/14873006/diff/11002/include/core/SkTemplates.h
File include/core/SkTemplates.h (right):

https://codereview.chromium.org/14873006/diff/11002/include/core/SkTemplates....
include/core/SkTemplates.h:112: T* set(T* ptr) {
On 2013/05/06 18:09:58, reed1 wrote:
> Do we have this pattern (where we return the old as we accept a new) in other
> helpers? It is certainly different from reset(), which always disposes of the
> old while accepting the new...

Hmmm... not really. This is mostly copy-pasta from Types.h but with templates.
It appears that this 'set' method is called by SkBitSet and SkPDFShader.
SkBitSet should probably use a SkTDArray, SkPDFShader should be using
SkAutoMalloc. Those two are using 'set' as something of a delayed constructor
(an init).

I actually do want an auto free because it's some other code making calls to
malloc, so I already have some malloc'ed memory. Adding to the complication is
that I also need to realloc, as the returned memory region is generally much too
big. A 'reset' doesn't play well with realloc. I'd like to avoid doing a
'detach' then a 'reset' in order to use realloc.

Perhaps the correct thing to do here is to simply not return the old value. Then
it is the callers responsibility to ensure that the old value magically should
not be freed. Since that is the job of detatch, perhaps realloc is the only
valid use of this sort of thing and it should be named/work as such. This
certainly makes my use case easier.

[bungeman-skia, 2013-05-06 21:55:49]

Patch set 6 feels better.

[reed1, 2013-05-07 13:29:48]

nit: SkTemplates.h is an 80-col file... until now

lgtm

[commit-bot: I haz the power, 2013-05-07 14:56:08]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/bungeman@google.com/14873006/27001

[commit-bot: I haz the power, 2013-05-07 15:05:01]

Retried try job too often on Build-Ubuntu12-GCC-x86_64-Release-Trybot for
step(s) BuildBench, BuildGM, BuildMost, BuildSkiaBaseLibs, BuildTests,
BuildTools
http://108.170.217.252:10117/buildstatus?builder=Build-Ubuntu12-GCC-x86_64-Re...

[commit-bot: I haz the power, 2013-05-07 15:21:31]

CQ is trying da patch. Follow status at
https://skia-tree-status.appspot.com/cq/bungeman@google.com/14873006/36001

[commit-bot: I haz the power, 2013-05-07 15:28:21]

Change committed as 9037