Update GrTRecorder to preserve memory allocations

Update GrTRecorder to preserve memory allocations

Rather than freeing almost all of its memory on calls to reset(), this
change updates GrTRecorder so it keeps around enough to satisfy the
storage requirements from last time, plus up to ~50% growth. This is
based on the assumption that subsequent draw calls require roughly the
same amount of memory.

BUG=skia:

Committed: https://skia.googlesource.com/skia/+/c4650ee786f1420f548bcc33b207b83244474351

[Chris Dalton, 2014-11-07 19:38:46]

cdalton@nvidia.com changed reviewers:
+ bsalomon@google.com

[Chris Dalton, 2014-11-07 19:38:47]

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrInOrderDrawBuf...
File src/gpu/GrInOrderDrawBuffer.h (right):

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrInOrderDrawBuf...
src/gpu/GrInOrderDrawBuffer.h:304: kCmdBufferInitialSizeInBytes = 8 * 1024,
This was arbitrary. The idea is that, since GrTRecorder preserves memory now, we
don't need to be quite so aggressive with the size of its initial allocation.
But it should still be relatively large for scenarios like alternating between
long and short draw calls.

[bsalomon, 2014-11-07 20:06:42]

lgtm

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrInOrderDrawBuf...
File src/gpu/GrInOrderDrawBuffer.h (right):

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrInOrderDrawBuf...
src/gpu/GrInOrderDrawBuffer.h:304: kCmdBufferInitialSizeInBytes = 8 * 1024,
On 2014/11/07 19:38:47, Chris Dalton wrote:
> This was arbitrary. The idea is that, since GrTRecorder preserves memory now,
we
> don't need to be quite so aggressive with the size of its initial allocation.
> But it should still be relatively large for scenarios like alternating between
> long and short draw calls.

makes sense to me

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrTRecorder.h
File src/gpu/GrTRecorder.h (right):

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrTRecorder.h#ne...
src/gpu/GrTRecorder.h:223: // Assume the next time this recorder fills up it
will use approximately the same
In the future we might want to consider exposing control of the functionality to
the caller.

[Chris Dalton, 2014-11-07 20:42:40]

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrTRecorder.h
File src/gpu/GrTRecorder.h (right):

https://codereview.chromium.org/684203003/diff/20001/src/gpu/GrTRecorder.h#ne...
src/gpu/GrTRecorder.h:223: // Assume the next time this recorder fills up it
will use approximately the same
On 2014/11/07 20:06:42, bsalomon wrote:
> In the future we might want to consider exposing control of the functionality
to
> the caller.

Agreed.

[Chris Dalton, 2014-11-07 20:42:43]

The CQ bit was checked by cdalton@nvidia.com

[commit-bot: I haz the power, 2014-11-07 20:43:41]

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

[commit-bot: I haz the power, 2014-11-07 20:51:24]

Committed patchset #2 (id:20001) as
https://skia.googlesource.com/skia/+/c4650ee786f1420f548bcc33b207b83244474351