Early reporting of opaqueness by decoders.

Early reporting of opaqueness by decoders.

Attempt to report opaqueness before decoding by using information
parsed from header for GIF, JPEG and PNG.

Caveat: frames reported as transparent could after decoding be
opaque. Opposite is not possible except when there was error in
decoding.

BUG=593430

[aleksandar.stojiljkovic, 2016-05-11 16:04:52]

aleksandar.stojiljkovic@intel.com changed reviewers:
+ schenney@chromium.org, scroggo@chromium.org

[aleksandar.stojiljkovic, 2016-05-11 16:04:53]

I'm aware that @schenney has already started work on this.
Not sure this code even does what it is supposed to to but it might help.
PNG part is not yet tested.

[aleksandar.stojiljkovic, 2016-05-16 12:57:46]

Description was changed from

==========
Early reporting of opaqeness by decoders.

Attempt to report opaqeness before decoding by using information
parsed from header for GIF, JPEG and PNG.

Caveat: frames reported as transparent could after decoding be
opaque. Opposite is not possible except when there was error in
decoding.

BUG=593430
==========

to

==========
Early reporting of opaqueness by decoders.

Attempt to report opaqueness before decoding by using information
parsed from header for GIF, JPEG and PNG.

Caveat: frames reported as transparent could after decoding be
opaque. Opposite is not possible except when there was error in
decoding.

BUG=593430
==========

[scroggo_chromium, 2016-05-16 20:38:20]

https://codereview.chromium.org/1972683002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp
(right):

https://codereview.chromium.org/1972683002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/image-decoders/gif/GIFImageDecoder.cpp:98: if
(frameContext.transparentPixel() >= colorTable.size())
Isn't it also possible that this frame does not cover the frame behind it, which
may have transparency? (Or, for that matter, could it have no frames behind it?
Wouldn't that also result in transparency?)

https://codereview.chromium.org/1972683002/diff/1/third_party/WebKit/Source/p...
File third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp
(right):

https://codereview.chromium.org/1972683002/diff/1/third_party/WebKit/Source/p...
third_party/WebKit/Source/platform/image-decoders/jpeg/JPEGImageDecoder.cpp:758:
if (index == 0 && isAllDataReceived())
I don't think this is quite correct. It's possible we've received all the data,
but the stream is truncated, so the frame is not complete, thus it has
transparency at the bottom.

[Stephen Chennney, 2016-05-18 20:23:34]

I think the bug has relevant discussion. We decided not to go with this approach
because code that used opacity information from the header may not display
hidden content while the image decodes, which is a less good user experience
than considering the image to be transparent during loading.

The preferred approach is to correctly report the decoding of the image back
from the raster thread to the Blink thread, somehow. It may be as simple as
correctly hooking up ImageObservers. I was planning on dealing with this after I
fix the issues with the compositor image caching, but feel free to take over
sooner.

[aleksandar.stojiljkovic, 2016-06-07 19:15:56]

On 2016/05/18 20:23:34, Stephen Chennney wrote:
> I think the bug has relevant discussion. We decided not to go with this
approach
> because code that used opacity information from the header may not display
> hidden content while the image decodes, which is a less good user experience
> than considering the image to be transparent during loading.

Thanks. Closing.

> 
> The preferred approach is to correctly report the decoding of the image back
> from the raster thread to the Blink thread, somehow. It may be as simple as
> correctly hooking up ImageObservers. I was planning on dealing with this after
I
> fix the issues with the compositor image caching, but feel free to take over
> sooner.