use SkData::NewUninitialized

use SkData::NewUninitialized

BUG=skia:

[reed2, 2014-09-12 03:00:44]

reed@chromium.org changed reviewers:
+ bungeman@google.com

[reed2, 2014-09-12 03:00:52]

The CQ bit was checked by reed@chromium.org

[commit-bot: I haz the power, 2014-09-12 03:02:00]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patchset/568683002/20001

[commit-bot: I haz the power, 2014-09-12 03:02:00]

Note for Reviewers:
The CQ is waiting for an approval.
If you believe that the CL is not ready yet, or if you would like to L-G-T-M
with comments then please uncheck the CQ checkbox.

Waiting for LGTM from a valid reviewer till 2014-09-12 09:02 UTC

[commit-bot: I haz the power, 2014-09-12 09:02:09]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2014-09-12 09:02:10]

No LGTM from a valid reviewer yet. Please ask for an LGTM from a
full Skia committer from
https://skia.googlesource.com/skia/+/master/CQ_COMMITTERS

[bungeman-skia, 2014-09-12 14:50:27]

Note also the existing implementations in SkStream.cpp which are declared in
SkStreamPriv.h.

https://codereview.chromium.org/568683002/diff/20001/include/core/SkStream.h
File include/core/SkStream.h (right):

https://codereview.chromium.org/568683002/diff/20001/include/core/SkStream.h#...
include/core/SkStream.h:64: SkData* readIntoData(size_t size);
Eck, not another thing on SkStream...

It seems like this might be better (both in implementation and use) as

SkData* SkData::NewFromStream(SkStream* stream, size_t length = SIZE_MAX)

This gets this away from being yet another helper on SkStream. Since this isn't
virtual and always just calls public api and makes a copy of the stream data
anyway, it seems more clear that this is a SkData creator.

In the future this could even rely on a virtual 'SkData* refData()' which would
replace or augment getMemoryBase to not create a copy if the whole stream needed
to be duplicated into an SkData.

At the very least this would go into the readXXX non-virtual ghetto below.

https://codereview.chromium.org/568683002/diff/20001/tools/lua/lua_pictures.cpp
File tools/lua/lua_pictures.cpp (right):

https://codereview.chromium.org/568683002/diff/20001/tools/lua/lua_pictures.c...
tools/lua/lua_pictures.cpp:89: SkAutoDataUnref
data(SkData::NewFromFileName(FLAGS_luaFile[i]));
Seems that you still need to test for non NULL data here (like lua_app.cpp)? If
not, then lua_app.cpp shouldn't have it either.

[reed1, 2014-09-12 18:46:09]

reed@google.com changed reviewers:
+ reed@google.com

[reed1, 2014-09-12 18:46:10]

moved to https://codereview.chromium.org/565803005/

[reed1, 2014-09-12 18:55:17]

https://codereview.chromium.org/568683002/diff/20001/include/core/SkStream.h
File include/core/SkStream.h (right):

https://codereview.chromium.org/568683002/diff/20001/include/core/SkStream.h#...
include/core/SkStream.h:64: SkData* readIntoData(size_t size);
On 2014/09/12 14:50:27, bungeman1 wrote:
> Eck, not another thing on SkStream...
> 
> It seems like this might be better (both in implementation and use) as
> 
> SkData* SkData::NewFromStream(SkStream* stream, size_t length = SIZE_MAX)
> 
> This gets this away from being yet another helper on SkStream. Since this
isn't
> virtual and always just calls public api and makes a copy of the stream data
> anyway, it seems more clear that this is a SkData creator.
> 
> In the future this could even rely on a virtual 'SkData* refData()' which
would
> replace or augment getMemoryBase to not create a copy if the whole stream
needed
> to be duplicated into an SkData.
> 
> At the very least this would go into the readXXX non-virtual ghetto below.

Done.

https://codereview.chromium.org/568683002/diff/20001/tools/lua/lua_pictures.cpp
File tools/lua/lua_pictures.cpp (right):

https://codereview.chromium.org/568683002/diff/20001/tools/lua/lua_pictures.c...
tools/lua/lua_pictures.cpp:89: SkAutoDataUnref
data(SkData::NewFromFileName(FLAGS_luaFile[i]));
On 2014/09/12 14:50:27, bungeman1 wrote:
> Seems that you still need to test for non NULL data here (like lua_app.cpp)?
If
> not, then lua_app.cpp shouldn't have it either.

Done.