Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

This is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.

2 layout tests are deleted under fast/canvas/. The reason is that
these layout tests uses 2d canvas to display an ImageBitmap,
and it cannot distinguish an ImageBitmap created with premultiplyAlpha=
false with an ImageBitmap created with true. Now that we have
a large set of layout tests under fast/canvas/webgl, these 2 tests
are redundant.

Committed: https://crrev.com/eb0d622c183ae08eb51e1ca68b84cbb16c564363
Cr-Commit-Position: refs/heads/master@{#383004}

[xidachen, 2016-03-22 14:02:09]

Description was changed from

==========
Correct small mistake in createImageBitmap from Blob and HTMLImageElement

This correction is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
Without this change, the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong.

We follow the example of WebGLImageConversion::ImageExtractor which takes
an Image as input, produces a SkImage and apply SkImage::readPixels to
get the pixel value. The tricky part is that when calling SkImage::readPixels,
this function always uses kPremul_SkAlphaType. Comparing to that, the
ImageBitmap::copyBitmapData calls SkImage::readPixels with a
kUnpremul_SkAlphaType if the input parameter premultiplyAlpha=false.

So this CL make correction for the case of createImageBitmap from Blob
and HTMLImageElement such that the ImageBitmap::copyBitmapData always uses
kPremul_SkAlphaType.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image.
==========

to

==========
Correct small mistake in createImageBitmap from Blob and HTMLImageElement

This correction is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.
==========

[xidachen, 2016-03-23 01:01:20]

Description was changed from

==========
Correct small mistake in createImageBitmap from Blob and HTMLImageElement

This correction is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.
==========

to

==========
Correct small mistake in createImageBitmap from HTMLImageElement

This correction is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.
==========

[xidachen, 2016-03-23 11:03:34]

xidachen@chromium.org changed reviewers:
+ junov@chromium.org

[xidachen, 2016-03-23 11:03:35]

PTAL

[Justin Novosad, 2016-03-23 14:08:25]

Can you explain the deleted tests?

Please provide a more descriptive subject. It should at leat have the word
"alpha" in it. "small mistake" does not tell us anything useful.  When scanning
through change logs, it is important to be able to get a clear idea of what each
change is about just from the headline.

https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap-from-canvas.html
(right):

https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap-from-canvas.html:21:
var halfRed = [26, 0, 0];
Not quite "half". perhaps call it "dim" or "dark".  Same for all the other
tests.

https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap.html
(left):

https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap.html:1:
<!DOCTYPE html>
Weird that this file is marled as modified, rather than deleted.

[Justin Novosad, 2016-03-23 14:09:26]

On 2016/03/23 14:08:25, Justin Novosad wrote:
> Weird that this file is marled as modified, rather than deleted.
I meant "marked".

[xidachen, 2016-03-23 14:24:39]

Description was changed from

==========
Correct small mistake in createImageBitmap from HTMLImageElement

This correction is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.
==========

to

==========
Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

This is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.

2 layout tests are deleted under fast/canvas/. The reason is that
these layout tests uses 2d canvas to display an ImageBitmap, 
and it cannot distinguish an ImageBitmap created with premultiplyAlpha=
false with an ImageBitmap created with true. Now that we have
a large set of layout tests under fast/canvas/webgl, these 2 tests
are redundant.
==========

[xidachen, 2016-03-23 14:25:55]

On 2016/03/23 14:09:26, Justin Novosad wrote:
> On 2016/03/23 14:08:25, Justin Novosad wrote:
> > Weird that this file is marled as modified, rather than deleted.
> I meant "marked".

The subject is updated, and also added a paragraph at the end of the
description, to explain why those 2 layout tests are deleted.

[xidachen, 2016-03-23 15:51:36]

https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
File
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap-from-canvas.html
(right):

https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap-from-canvas.html:21:
var halfRed = [26, 0, 0];
On 2016/03/23 14:08:25, Justin Novosad wrote:
> Not quite "half". perhaps call it "dim" or "dark".  Same for all the other
> tests.

Done.

[Justin Novosad, 2016-03-23 20:43:15]

On 2016/03/23 15:51:36, xidachen wrote:
>
https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
> File
>
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap-from-canvas.html
> (right):
> 
>
https://codereview.chromium.org/1809603004/diff/40001/third_party/WebKit/Layo...
>
third_party/WebKit/LayoutTests/fast/canvas/webgl/tex-image-and-sub-image-2d-image-bitmap-from-image-bitmap-from-canvas.html:21:
> var halfRed = [26, 0, 0];
> On 2016/03/23 14:08:25, Justin Novosad wrote:
> > Not quite "half". perhaps call it "dim" or "dark".  Same for all the other
> > tests.
> 
> Done.

lgtm

[xidachen, 2016-03-23 20:45:11]

The CQ bit was checked by xidachen@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-03-23 20:45:28]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1809603004/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1809603004/60001

[commit-bot: I haz the power, 2016-03-23 23:05:41]

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

[commit-bot: I haz the power, 2016-03-23 23:05:42]

Dry run: This issue passed the CQ dry run.

[xidachen, 2016-03-24 01:19:38]

The CQ bit was checked by xidachen@chromium.org

[commit-bot: I haz the power, 2016-03-24 01:19:54]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1809603004/60001
View timeline at
 https://chromium-cq-status.appspot.com/patch-timeline/1809603004/60001

[commit-bot: I haz the power, 2016-03-24 01:25:30]

Description was changed from

==========
Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

This is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.

2 layout tests are deleted under fast/canvas/. The reason is that
these layout tests uses 2d canvas to display an ImageBitmap, 
and it cannot distinguish an ImageBitmap created with premultiplyAlpha=
false with an ImageBitmap created with true. Now that we have
a large set of layout tests under fast/canvas/webgl, these 2 tests
are redundant.
==========

to

==========
Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

This is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.

2 layout tests are deleted under fast/canvas/. The reason is that
these layout tests uses 2d canvas to display an ImageBitmap, 
and it cannot distinguish an ImageBitmap created with premultiplyAlpha=
false with an ImageBitmap created with true. Now that we have
a large set of layout tests under fast/canvas/webgl, these 2 tests
are redundant.
==========

[commit-bot: I haz the power, 2016-03-24 01:25:31]

Committed patchset #4 (id:60001)

[commit-bot: I haz the power, 2016-03-24 01:28:06]

Description was changed from

==========
Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

This is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the 
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement 
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.

2 layout tests are deleted under fast/canvas/. The reason is that
these layout tests uses 2d canvas to display an ImageBitmap, 
and it cannot distinguish an ImageBitmap created with premultiplyAlpha=
false with an ImageBitmap created with true. Now that we have
a large set of layout tests under fast/canvas/webgl, these 2 tests
are redundant.
==========

to

==========
Use ImageDecoder for createImageBitmap(HTMLImageElement, premultiplyAlpha=false)

This is specifically for the case of premultiplyAlpha=false.
Following is an example. Given an image with only one pixel with value of
(255, 0, 0, 26), and we load the this image either as a Blob or a
HTMLImageElement and call createImageBitmap with premultiplyAlpha=false.
the ImageBitmap::copyBitmapData will return a pixel
value of (197, 0, 0, 26) which is totally wrong. The reason it fails
is that the SkImage that is extracted from ImageDecoder is always
in kPremul alphaType even if "AlphaNotPremultiplied" is given to
the ImageDecoder.

With this CL: https://codereview.chromium.org/1820733004/, the
extracted SkImage now has a kUnpremul alphaType. ImageBitmap
should adapt to this change as well. So this CL make correction
for the case of createImageBitmap from Blob and HTMLImageElement
so that copyBitmapData will succeed with the SkImage extracted
from ImageDecoder.

We have also updated corresponding layout tests. In particular, we change
an existing image's alpha channel from 128 to 26. In this case, if the
ImageBitmap constructor handles premultiplyAlpha=false by first premultiply
and then un-premultiply, we will see a large loss comparing with input.
Here we can see that the color is very close (tolerance of 2) to its input
image. Additionally, we added several new layout tests to test the
cases of createImageBitmap(ImageBitmap) where the parameter ImageBitmap
is created from various kinds of sources.

2 layout tests are deleted under fast/canvas/. The reason is that
these layout tests uses 2d canvas to display an ImageBitmap,
and it cannot distinguish an ImageBitmap created with premultiplyAlpha=
false with an ImageBitmap created with true. Now that we have
a large set of layout tests under fast/canvas/webgl, these 2 tests
are redundant.

Committed: https://crrev.com/eb0d622c183ae08eb51e1ca68b84cbb16c564363
Cr-Commit-Position: refs/heads/master@{#383004}
==========

[commit-bot: I haz the power, 2016-03-24 01:28:06]

Patchset 4 (id:??) landed as
https://crrev.com/eb0d622c183ae08eb51e1ca68b84cbb16c564363
Cr-Commit-Position: refs/heads/master@{#383004}