Replacing alloca call in SkTileGrid with SkAutoSMalloc

Replacing alloca call in SkTileGrid with SkAutoSMalloc
Committed: https://code.google.com/p/skia/source/detail?r=6824

[junov1, 2012-12-14 19:50:45]

PTAL

[reed1, 2012-12-14 19:54:45]

SkAutoSTMalloc might be clearer.

SkAutoSTMalloc<1024, SkTDArray*> storage(count);
SkTDArray** array = storage.get();

[reed1, 2012-12-14 19:56:35]

or SkAutoSTArray, which is equivalent (in behavior) to SkAutoSTMalloc if T is a
POD (which yours is).

[junov1, 2012-12-14 19:59:56]

On 2012/12/14 19:56:35, reed1 wrote:
> or SkAutoSTArray, which is equivalent (in behavior) to SkAutoSTMalloc if T is
a
> POD (which yours is).

patch

[reed1, 2012-12-14 20:02:04]

lgtm

might add a comment above the 1024, describing why that seems like a good guess
(not sure of your reasoning).

[junov1, 2012-12-14 20:08:02]

I totally pulled that number out of my rear, which does not seam like an
appropriate comment.

On 2012/12/14 20:02:04, reed1 wrote:
> lgtm
> 
> might add a comment above the 1024, describing why that seems like a good
guess
> (not sure of your reasoning).

[reed1, 2012-12-14 20:19:56]

Then (perhaps), we should not use it. Can you run this on some
pictures, and get a feel for what value might be appropriate? Perhaps
we can just use the heap all the time, rather than complicate it with
stack-based allocations, unless we feel this is performance critical.

On Fri, Dec 14, 2012 at 3:08 PM,  <junov@chromium.org> wrote:
> I totally pulled that number out of my rear, which does not seam like an
> appropriate comment.
>
>
> On 2012/12/14 20:02:04, reed1 wrote:
>>
>> lgtm
>
>
>> might add a comment above the 1024, describing why that seems like a
>
> good guess
>>
>> (not sure of your reasoning).
>
>
>
>
> https://codereview.appspot.com/6946054/

[junov1, 2012-12-14 20:24:22]

A typical big page, say  2k x 16k would have 512 tiles.

On Fri, Dec 14, 2012 at 3:19 PM, Mike Reed <reed@google.com> wrote:

> Then (perhaps), we should not use it. Can you run this on some
> pictures, and get a feel for what value might be appropriate? Perhaps
> we can just use the heap all the time, rather than complicate it with
> stack-based allocations, unless we feel this is performance critical.
>
> On Fri, Dec 14, 2012 at 3:08 PM,  <junov@chromium.org> wrote:
> > I totally pulled that number out of my rear, which does not seam like an
> > appropriate comment.
> >
> >
> > On 2012/12/14 20:02:04, reed1 wrote:
> >>
> >> lgtm
> >
> >
> >> might add a comment above the 1024, describing why that seems like a
> >
> > good guess
> >>
> >> (not sure of your reasoning).
> >
> >
> >
> >
> > https://codereview.appspot.com/6946054/
>

[reed1, 2012-12-14 20:27:44]

That sounds like a great thing for a comment!

On Fri, Dec 14, 2012 at 3:24 PM, Justin Novosad <junov@chromium.org> wrote:
> A typical big page, say  2k x 16k would have 512 tiles.
>
>
> On Fri, Dec 14, 2012 at 3:19 PM, Mike Reed <reed@google.com> wrote:
>>
>> Then (perhaps), we should not use it. Can you run this on some
>> pictures, and get a feel for what value might be appropriate? Perhaps
>> we can just use the heap all the time, rather than complicate it with
>> stack-based allocations, unless we feel this is performance critical.
>>
>> On Fri, Dec 14, 2012 at 3:08 PM,  <junov@chromium.org> wrote:
>> > I totally pulled that number out of my rear, which does not seam like an
>> > appropriate comment.
>> >
>> >
>> > On 2012/12/14 20:02:04, reed1 wrote:
>> >>
>> >> lgtm
>> >
>> >
>> >> might add a comment above the 1024, describing why that seems like a
>> >
>> > good guess
>> >>
>> >> (not sure of your reasoning).
>> >
>> >
>> >
>> >
>> > https://codereview.appspot.com/6946054/
>
>