tree 5c116161612fdf72d000988b738dcdf1935f78e8
parent 989ac549c16d583297cd1d9ab814bfa59573b950
author commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> 1392316554 +0000
committer commit-bot@chromium.org <commit-bot@chromium.org@2bbb7eff-a529-9590-31e7-b0007b416f81> 1392316554 +0000

SkWriter32: throw in the SkTDArray towel.

I think it's looking more clear we don't have a clean way to use SkTDArray in
SkWriter32.  We can't give SkWriter32 meaningful control over SkTDArray's
reallocation without making moot SkTDArray's raison d'etre.

Let's just use an SkAutoTMalloc<uint8_t> instead.  It wants SkWriter32 to
control it.  Also, it's lower overhead: SkAutoTMalloc<uint8_t> is just a smart
poiter: no size or capacity stored.

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

Author: mtklein@chromium.org

Review URL: https://codereview.chromium.org/163983002

git-svn-id: http://skia.googlecode.com/svn/trunk@13436 2bbb7eff-a529-9590-31e7-b0007b416f81