Correction of SampleApp Windows build-break.

Correction of the non-portable use of dynamically allocated stack arrays in the pdf shader code.

I briefly looked into making use of alloca, but that is also non-portable, and deprecated in many environments.  Fell back to the SkTDArray class as a common denominator.

This problem was introduce by the following CL: http://codereview.appspot.com/4239061/

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

[twiz1, 2011-03-09 21:43:13]

PTAL.

[reed1, 2011-03-09 21:57:06]

SkAutoSMalloc and SkAutoSTMalloc might also be used, as they allow the caller to
use the stack for small requests...

SkAutoSMalloc<1024> storage(request);

if request <= 1024, it will be taken from the stack.

[Steve VanDeBogart, 2011-03-09 22:00:15]

I'd rather use malloc + SkAutoTDelete than SkTDArray because SkTDArray will
reserve some space for growth (growBy does size = cur + requested + 4; size +=
size/4).  But these functions are short lived and the arrays should be small so
it doesn't matter much one way or another.

LGTM

[twiz1, 2011-03-09 22:10:03]

On 2011/03/09 21:57:06, reed1 wrote:
> SkAutoSMalloc and SkAutoSTMalloc might also be used, as they allow the caller
to
> use the stack for small requests...
> 
> SkAutoSMalloc<1024> storage(request);
> 
> if request <= 1024, it will be taken from the stack.

I actually had an implementation using those exact classes, but used the array
class because it looked cleaner.  (Fewer reinterpret casts, etc.)

Since you recommend this approach, I'll use those stack-allocating classes.

Jeff