PDF: remove unused SkPDFDevice::setDCTEncoder()

PDF: remove unused SkPDFDevice::setDCTEncoder()

All image compression currently uses (losseless) Deflate, not
Jpeg.  See http://crrev.com/935843007

Committed: https://skia.googlesource.com/skia/+/07d5947b886bef06621e830e9f8bf253f9bad703

[hal.canary, 2015-02-20 03:19:21]

halcanary@google.com changed reviewers:
+ mtklein@google.com

[hal.canary, 2015-02-20 03:19:22]

PTAL

I have no idea what order these should land in.  I'll rebase as necessary.

[hal.canary, 2015-02-20 03:20:08]

The CQ bit was checked by halcanary@google.com

[commit-bot: I haz the power, 2015-02-20 03:20:15]

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

[commit-bot: I haz the power, 2015-02-20 03:20:16]

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 valid reviewer(s) till 2015-02-20 09:20 UTC

[commit-bot: I haz the power, 2015-02-20 03:21:55]

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

[commit-bot: I haz the power, 2015-02-20 03:21:56]

Try jobs failed on following builders:
  Build-Ubuntu13.10-Clang-x86_64-Debug-Trybot on client.skia.compile
(JOB_FAILED,
http://build.chromium.org/p/client.skia.compile/builders/Build-Ubuntu13.10-Cl...)

[hal.canary, 2015-02-20 03:25:34]

The CQ bit was checked by halcanary@google.com

[commit-bot: I haz the power, 2015-02-20 03:26:15]

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

[commit-bot: I haz the power, 2015-02-20 03:26:16]

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 valid reviewer(s) till 2015-02-20 09:26 UTC

[mtklein, 2015-02-20 03:36:13]

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFDevice.cpp
File src/pdf/SkPDFDevice.cpp (left):

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFDevice.cpp#...
src/pdf/SkPDFDevice.cpp:730: , fEncoder(NULL)
So... this was just always NULL?

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.cpp
File src/pdf/SkPDFImage.cpp (right):

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.cpp#n...
src/pdf/SkPDFImage.cpp:591: // Initializing image data for the first time.
Do both these comments still make sense here?

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.h
File src/pdf/SkPDFImage.h (left):

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.h#old...
src/pdf/SkPDFImage.h:27: *  If the bitmap has encoded JPEG data and that data
can be embedded
This seems like a good idea, both to build a better .pdf and to use less memory
to build it.

Does this CL disable this, or were we just lying before?  Was that what the
unused "encoder" was for?

[commit-bot: I haz the power, 2015-02-20 09:26:22]

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

[commit-bot: I haz the power, 2015-02-20 09:26:23]

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

[hal.canary, 2015-02-20 12:52:57]

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFDevice.cpp
File src/pdf/SkPDFDevice.cpp (left):

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFDevice.cpp#...
src/pdf/SkPDFDevice.cpp:730: , fEncoder(NULL)
On 2015/02/20 03:36:13, mtklein wrote:
> So... this was just always NULL?

The constructor never sets it.  You had to call ->setDCTEncoder(), which in
practice no one ever did.  Then I landed http://crrev.com/935843007 , which took
away the possibility that they will in the future.

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.cpp
File src/pdf/SkPDFImage.cpp (right):

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.cpp#n...
src/pdf/SkPDFImage.cpp:591: // Initializing image data for the first time.
On 2015/02/20 03:36:13, mtklein wrote:
> Do both these comments still make sense here?

Yes.  This class caches the Deflate-encoded data (via ->setData()).  I will
completely remove this class very soon (as soon as I teach SkPDFBitmap to handle
non-8888 bitmaps).

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.h
File src/pdf/SkPDFImage.h (left):

https://codereview.chromium.org/946493002/diff/20001/src/pdf/SkPDFImage.h#old...
src/pdf/SkPDFImage.h:27: *  If the bitmap has encoded JPEG data and that data
can be embedded
On 2015/02/20 03:36:13, mtklein wrote:
> This seems like a good idea, both to build a better .pdf and to use less
memory
> to build it.
> 
> Does this CL disable this, or were we just lying before?  Was that what the
> unused "encoder" was for?

This was a separate bit of logic that had a bug in it that I `#if 0`ed out in
http://crrev.com/767343002 .

fEncoder encodes *every* image to JPEG.  This seems like the wrong thing, so I
am killing it.

[mtklein, 2015-02-20 13:01:12]

lgtm

[hal.canary, 2015-02-20 13:51:59]

The CQ bit was checked by halcanary@google.com

[commit-bot: I haz the power, 2015-02-20 13:53:03]

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

[commit-bot: I haz the power, 2015-02-20 13:53:07]

This issue passed the CQ. To commit it, remove "COMMIT=false" from
the description and try again.

[hal.canary, 2015-02-20 13:56:03]

The CQ bit was checked by halcanary@google.com

[commit-bot: I haz the power, 2015-02-20 13:57:03]

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

[commit-bot: I haz the power, 2015-02-20 13:57:17]

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