Fix failure exits from JPEG onBuildTileIndex.

Fix failure exits from JPEG onBuildTileIndex.

The setjmp exited without deleting the SkJPEGImageIndex, and
another exit condition deleted the huffman index even though
it had not been created yet. Create member functions on
SkJPEGImageIndex to make the jpeg calls so it can keep track
of what has been created, and avoid destroying anything else.

Remove unnecessary lines to set values to their default values.

Move all SkJPEGImageIndex code entirely inside #ifdef ANDROID
blocks, since no piece of it is used except by ANDROID only
code.

BUG=skia:1471
R=djsollen@google.com, mtklein@google.com

Committed: https://code.google.com/p/skia/source/detail?r=10628

[djsollen, 2013-08-05 12:16:24]

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
File src/images/SkImageDecoder_libjpeg.cpp (left):

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
src/images/SkImageDecoder_libjpeg.cpp:495: cinfo->do_block_smoothing = 0;
You don't initialize these value in the initializeInfoAndReadHeader function. 
Is that intentional?

[scroggo, 2013-08-05 13:27:36]

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
File src/images/SkImageDecoder_libjpeg.cpp (left):

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
src/images/SkImageDecoder_libjpeg.cpp:495: cinfo->do_block_smoothing = 0;
On 2013/08/05 12:16:24, djsollen wrote:
> You don't initialize these value in the initializeInfoAndReadHeader function. 
> Is that intentional?

Yes. This set that I removed actually does nothing, since jpeg_read_header sets
them to 1. And not setting them after the first call to jpeg_read_header retains
the current behavior.

[djsollen, 2013-08-05 13:38:04]

lgtm

[mtklein, 2013-08-05 14:10:43]

lgtm

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
File src/images/SkImageDecoder_libjpeg.cpp (right):

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
src/images/SkImageDecoder_libjpeg.cpp:113: bool success = (JPEG_HEADER_OK ==
jpeg_read_header(&fCInfo, true));
I like to tack on const where possible.

[scroggo, 2013-08-05 14:33:44]

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
File src/images/SkImageDecoder_libjpeg.cpp (right):

https://codereview.chromium.org/21891007/diff/3001/src/images/SkImageDecoder_...
src/images/SkImageDecoder_libjpeg.cpp:113: bool success = (JPEG_HEADER_OK ==
jpeg_read_header(&fCInfo, true));
On 2013/08/05 14:10:43, mtklein wrote:
> I like to tack on const where possible.

Agreed. Done.

[scroggo, 2013-08-05 15:18:41]

https://codereview.chromium.org/21891007/diff/15001/src/images/SkImageDecoder...
File src/images/SkImageDecoder_libjpeg.cpp (right):

https://codereview.chromium.org/21891007/diff/15001/src/images/SkImageDecoder...
src/images/SkImageDecoder_libjpeg.cpp:76: fDecompressStarted = false;
As mtklein pointed out, in patch set 3, if jpeg_finish_decompress called
longjmp, we would again delete the SkJPEGImageIndex, call
jpeg_finish_decompress, and end up right where we started. To avoid this
potential infinite loop, I have moved the state change to before calling the
jpeg function, so if it calls longjmp, we may fail to free resources, but we can
continue execution.

[mtklein, 2013-08-05 15:21:08]

On 2013/08/05 15:18:41, scroggo wrote:
>
https://codereview.chromium.org/21891007/diff/15001/src/images/SkImageDecoder...
> File src/images/SkImageDecoder_libjpeg.cpp (right):
> 
>
https://codereview.chromium.org/21891007/diff/15001/src/images/SkImageDecoder...
> src/images/SkImageDecoder_libjpeg.cpp:76: fDecompressStarted = false;
> As mtklein pointed out, in patch set 3, if jpeg_finish_decompress called
> longjmp, we would again delete the SkJPEGImageIndex, call
> jpeg_finish_decompress, and end up right where we started. To avoid this
> potential infinite loop, I have moved the state change to before calling the
> jpeg function, so if it calls longjmp, we may fail to free resources, but we
can
> continue execution.

lgtm

[scroggo, 2013-08-07 21:02:37]

Committed patchset #4 manually as r10628 (presubmit successful).