Just to be clear on the benefits:

I don't expect the binary size to change much - Skia's decoders are not built as a part of Chrome. They are used by the Android framework, but Chrome is an app that does not get to share the same copy of Skia, so it includes its own.

There are other benefits though:
- Skia already has some features that Chromium is interested in:
  - decoding scaled versions of images
  - decoding subsets (i.e. issue 468914)
  - SIMD optimizations for writing pixels
- In general, sharing code means that new features/bug fixes in Android
  benefit Chromium and vice versa
- Skia's API is designed to allow the client to handle caching, so that
  the client that knows the bigger picture can make caching decisions in a
  more informed way than ImageDecoder can. (I believe this is why issue
  507394 is referenced.)

All of the reasons here sound good. I think I'm just excited about a single set of codecs, since any improvements that we make won't have to be replicated to two different places.

Interesting Leon. I wondered if the SkCodec decoders support decode suspension.  The Blink images decoders do of course, and must, since we receive encoded data via network data packets).

They do.
We provide a reader that contains multiple buffers. We can append buffers as they arrive.

You can see the work being done here:
https://codereview.chromium.org/2565323003/

Sounds good.  For me suspension means from the callers side too: the caller calls decode() and the image decoders decode as much as they can and suspend ... JPEGImageDecoder is a good example, I/O suspension comments all over [1]

[1] https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp?q=JPEGImageDecoder&sq=package:chromium&dr=CSs&l=404

> You can see the work being done here:
https://codereview.chromium.org/2565323003/

IC and thank you for the link.

Timing measurements of the GIF decoder to make sure we do not regress:
https://docs.google.com/a/chromium.org/spreadsheets/d/18xPfE241z4-1hQdTBdFEJzDWbFZIPRyQ2ldBHoSHhqY/edit?usp=sharing
(requires @chromium.org account)

Hi cblume
Submitted WIP patch to move image decoders to skcodec. https://codereview.chromium.org/2930513004 by taking the reference of your patch https://codereview.chromium.org/2565323003

Please look into that

I commented on the CR but I'll add a small comment here, too.

Not all of Sk*Codec is ready, so we can't move to using them all in one step just yet.
In addition, this patch doesn't handle things we require like JPEG's YUV, progressive decoding, and first-frame transparency for partial decodes to name a few.

I would be happy to have your help if you would like to assist in the transition to SkCodec. The next big ticket is going to be changing SkJpegCodec to work for all of Chromium's cases. We can talk more about that if you're interested.

Hi cblume
I am interested on this activity.

 - Submitted the preparation patch to move ImageDecoders to SkCodec.
      https://chromium-review.googlesource.com/c/558856/
 - Next planning to start SkJpegCodec to work for all of Chromium's cases. Need your help on this.
let me know if anything else is in high priority on the transition to SkCodec activity

Submitted WIP patch to move JPEG image decoders to SkCodec
https://chromium-review.googlesource.com/558340

Started working on this issue. Planned to implement the same by following way
  - Use skia to find the image codec type.
     - Submitted the patch https://chromium-review.googlesource.com/#/c/558856/
  - Move all image decoders to skia
     - Submitted the WIP patch for JPEG scenario https://chromium-review.googlesource.com/#/c/558340/
  - Remove all derived classes like JPEGDecoder, PNG decoder and etc. These classes are not required any more because all the decoding related things are moved to Skia. All others usescases are same for all classes. Merge all the changes in ImageDeocder class.
Let me know if I missed something or wrong in the idea

So you know, you are duplicating work.

If you would like to help, it would be wise to first find a bug that isn't assigned to someone. Or if you want to work on a bug that is assigned, contact the person it is assigned to and find out how you can help.

The JPEG work you did is something I had already done, as pointed out in the JPEG bug: https://bugs.chromium.org/p/chromium/issues/detail?id=715817

https://codereview.chromium.org/2777683002

Some of the work that needs to be done is inside SkJpegCodec itself. For example, scroggo@ just recently added a fix where there are now separate error codes for if the image is incomplete because we don't have enough data or if the image is incomplete because the image had an error. We should return the correct error code from inside SkJpegCodec. You can find that here: https://bugs.chromium.org/p/skia/issues/detail?id=6825

Ok I will take care of your above comments.

Submitted the patch to support incremental decoding in SkJpegCodec
https://skia-review.googlesource.com/#/c/21680/

Tested with Imagedecoder patch moving to skia it's working.

Not submitted the final patch to move Image decoding to skia for JPEG as it has a dependency with you patches

It seems that the current decoders have issue with decoding ICC embedded wide gamut images. For example, PNG decoder decodes the attached PNG images to transparent black. SkCodec decodes these images just fine.

Deleted: pattern-semitransparent-p3d65.png 5.8 KB

	pattern-semitransparent-p3d65.png 5.8 KB View Download

Deleted: pattern-semitransparent-srgb.png 5.2 KB

	pattern-semitransparent-srgb.png 5.2 KB View Download