Change code path for structured cloning ImageBitmap

Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we read the pixel
data according to whether the ImageBitmap is premultiplied or not,
also we store the information whether the bitmap is premultiplied or
not. When de-serialization happens, we design a new ImageBitmap
constructor specifically for it.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
Committed: https://crrev.com/58c08f3acefbd7a44387d03237967a4644130c0f
Cr-Commit-Position: refs/heads/master@{#403475}

[xidachen, 2016-06-27 18:03:52]

Description was changed from

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we always read the pixel
data in un-premultiplied format, also we store the information whether
the bitmap is premultiplied or not. When de-serialize happens, we call
the ImageBitmap::create(ImageData*) function. If the bitmap is
premultiplied/un-premultiplied, we create a new ImageBitmap that is
premultiplied/un-premultiplied.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
fast/canvas/canvas-ImageBitmap-structured-clone.html
pass.

BUG=615172
==========

to

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we always read the pixel
data in un-premultiplied format, also we store the information whether
the bitmap is premultiplied or not. When de-serialize happens, we call
the ImageBitmap::create(ImageData*) function. If the bitmap is
premultiplied/un-premultiplied, we create a new ImageBitmap that is
premultiplied/un-premultiplied.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
==========

[xidachen, 2016-06-27 18:42:54]

xidachen@chromium.org changed reviewers:
+ haraken@chromium.org, jbroman@chromium.org

[xidachen, 2016-06-27 18:42:55]

PTAL

[jbroman, 2016-06-27 19:16:16]

I'm a little confused here. Why read even premultiplied bitmaps back as
unpremultiplied?

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:261: // The last parameter
are used for structure-cloning.
nit: "The last parameter is...", or better yet, "isImageDataOriginClean is...".

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:339:
m_image->setOriginClean(isImageDataOriginClean);
Is this change related to this CL?

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/ImageBitmap.h (right):

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/ImageBitmap.h:40: static ImageBitmap*
create(ImageData*, const IntRect&, const ImageBitmapOptions& =
ImageBitmapOptions(), const bool& isImageDataOriginClean = true);
nit: not new here, but booleans should just be passed by value; it's not
necessary to pass them by const reference (i.e. "bool isImageDataOriginClean").

[xidachen, 2016-06-27 19:48:22]

Using an example is probably the best way to demonstrate why we read back the
un-premultiplied data.

Say that an ImageBitmap is created from ImageData(255, 0, 0, 128). Without this
CL, what happens is this:
1. Read premultiplied data: [128, 0, 0, 128]
2. Call ImageBitmap::create() with the above data and saying that this data is
already premultiplied. The code path goes into the huge if (!premultiplyAlpha)
block at line 269, which is specially designed to handle the request that do not
apply premultiply on the input data. However, in this case, the underline
SkImage is set to be kUnpremul_SkAlphaType, and that is problematic because this
SkImage should really be kPremul_SkAlphaType.

So the solution in this CL is:
1. Read un-premultiplied data [255, 0, 0, 128]
2. Call ImageBitmap::create() saying that this data is not premultiplied and
needs to be premultiplied. The underline SkImage is kPremul_SkAlphaType.

I hope that makes sense.

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:261: // The last parameter
are used for structure-cloning.
On 2016/06/27 19:16:16, jbroman wrote:
> nit: "The last parameter is...", or better yet, "isImageDataOriginClean
is...".

Done.

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:339:
m_image->setOriginClean(isImageDataOriginClean);
On 2016/06/27 19:16:16, jbroman wrote:
> Is this change related to this CL?

Without this CL, the code path for structured-cloning will never gets here, so
it is not needed to set the origin clean flag. With this CL, structured-cloning
an ImageBitmap can get here.

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/frame/ImageBitmap.h (right):

https://codereview.chromium.org/2039983002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/frame/ImageBitmap.h:40: static ImageBitmap*
create(ImageData*, const IntRect&, const ImageBitmapOptions& =
ImageBitmapOptions(), const bool& isImageDataOriginClean = true);
On 2016/06/27 19:16:16, jbroman wrote:
> nit: not new here, but booleans should just be passed by value; it's not
> necessary to pass them by const reference (i.e. "bool
isImageDataOriginClean").

Done.

[xidachen, 2016-06-28 18:13:55]

Description was changed from

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we always read the pixel
data in un-premultiplied format, also we store the information whether
the bitmap is premultiplied or not. When de-serialize happens, we call
the ImageBitmap::create(ImageData*) function. If the bitmap is
premultiplied/un-premultiplied, we create a new ImageBitmap that is
premultiplied/un-premultiplied.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
==========

to

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we read the pixel
data according to whether the ImageBitmap is premultiplied or not,
also we store the information whether the bitmap is premultiplied or 
not. When de-serialization happens, we design a new ImageBitmap
constructor specifically for it.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
==========

[xidachen, 2016-06-28 18:14:13]

This CL is now ready for re-review. Thanks.

[jbroman, 2016-06-28 18:50:22]

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp
(right):

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp:1761: if
(m_position + *pixelDataLength > m_length)
nit: Not introduced in this CL, but beware of overflow here.

Something like "m_position >= m_length || m_length - m_position <
*pixelDataLength" might be safer, because it doesn't cause overflow in the case
where m_position and m_length are close are close to
std::numeric_limits<unsigned>::max().

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp:1799:
DCHECK(pixelData);
DCHECK isn't necessary here; the renderer will crash if the allocation fails.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:262: //
isImageBitmapPremultiplied indicates whether the original ImageBitmap is
premultiplied or not.
Comments like this normally go in the header, since they describe how to call
the function correctly. I'd also specify in the comment that it specifies
whether the provided data contains premultiplied or unpremultiplied pixel data.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:267:
swizzleImageData(data.get(), height, info.bytesPerPixel() * width, false);
What's the purpose of this swizzling? Why aren't we serializing data in the most
convenient format to read it?

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:269:
swizzleImageData(data.get(), height, info.bytesPerPixel() * width, false);
Why unswizzle the data when we're about to delete it anyhow?

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.h (right):

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.h:45: static ImageBitmap*
create(std::unique_ptr<uint8_t[]>, uint32_t, uint32_t, bool, bool);
Please name these parameters, here and below. "uint32_t" and "bool" does not
explain what these are. Omitting parameter names is okay only when the name
would be obvious (e.g. so you don't have to write "ImageBitmapOptions
imageBitmapOptions").

[xidachen, 2016-06-29 12:58:35]

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp
(right):

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp:1761: if
(m_position + *pixelDataLength > m_length)
On 2016/06/28 18:50:22, jbroman wrote:
> nit: Not introduced in this CL, but beware of overflow here.
> 
> Something like "m_position >= m_length || m_length - m_position <
> *pixelDataLength" might be safer, because it doesn't cause overflow in the
case
> where m_position and m_length are close are close to
> std::numeric_limits<unsigned>::max().

Done.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp:1799:
DCHECK(pixelData);
On 2016/06/28 18:50:21, jbroman wrote:
> DCHECK isn't necessary here; the renderer will crash if the allocation fails.

Done.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:262: //
isImageBitmapPremultiplied indicates whether the original ImageBitmap is
premultiplied or not.
On 2016/06/28 18:50:22, jbroman wrote:
> Comments like this normally go in the header, since they describe how to call
> the function correctly. I'd also specify in the comment that it specifies
> whether the provided data contains premultiplied or unpremultiplied pixel
data.

Done.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:267:
swizzleImageData(data.get(), height, info.bytesPerPixel() * width, false);
On 2016/06/28 18:50:22, jbroman wrote:
> What's the purpose of this swizzling? Why aren't we serializing data in the
most
> convenient format to read it?

Done.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:269:
swizzleImageData(data.get(), height, info.bytesPerPixel() * width, false);
On 2016/06/28 18:50:22, jbroman wrote:
> Why unswizzle the data when we're about to delete it anyhow?

Done.

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.h (right):

https://codereview.chromium.org/2039983002/diff/100001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.h:45: static ImageBitmap*
create(std::unique_ptr<uint8_t[]>, uint32_t, uint32_t, bool, bool);
On 2016/06/28 18:50:22, jbroman wrote:
> Please name these parameters, here and below. "uint32_t" and "bool" does not
> explain what these are. Omitting parameter names is okay only when the name
> would be obvious (e.g. so you don't have to write "ImageBitmapOptions
> imageBitmapOptions").

Done.

[jbroman, 2016-06-29 15:10:34]

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp
(right):

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp:1761: if
(m_position + *pixelDataLength > m_length || m_length - m_position <
*pixelDataLength)
nit: I don't think you need to do the full check twice here, just account for
overflow.

The latter, "m_length - m_position < *pixelDataLength" is sufficient, as long as
you can rely on m_position not to be greater than m_length (which would
underflow). I think doReadUint32 promises that, so just that condition should
work. (My original suggestion also verified it, but that's not strictly
necessary).

As long as that underflow doesn't happen, this is fine and we don't need to do
the check with addition as well.

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:263: SkImageInfo info =
SkImageInfo::Make(width, height, kBGRA_8888_SkColorType,
isImageBitmapPremultiplied ? kPremul_SkAlphaType : kUnpremul_SkAlphaType);
Replied offline with questions about the use of kBGRA_8888_SkColorType here.

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.h (right):

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.h:60:
std::unique_ptr<uint8_t[]> copyBitmapData(AlphaDisposition alphaOp =
DontPremultiplyAlpha, DataColorFormat format = RGBAColorType);
By the way, you could just use SkAlphaType and SkColorType if you didn't want to
add additional ones here.

[xidachen, 2016-06-29 15:51:14]

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp
(right):

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.cpp:1761: if
(m_position + *pixelDataLength > m_length || m_length - m_position <
*pixelDataLength)
On 2016/06/29 15:10:33, jbroman wrote:
> nit: I don't think you need to do the full check twice here, just account for
> overflow.
> 
> The latter, "m_length - m_position < *pixelDataLength" is sufficient, as long
as
> you can rely on m_position not to be greater than m_length (which would
> underflow). I think doReadUint32 promises that, so just that condition should
> work. (My original suggestion also verified it, but that's not strictly
> necessary).
> 
> As long as that underflow doesn't happen, this is fine and we don't need to do
> the check with addition as well.

Done.

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/120001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:263: SkImageInfo info =
SkImageInfo::Make(width, height, kBGRA_8888_SkColorType,
isImageBitmapPremultiplied ? kPremul_SkAlphaType : kUnpremul_SkAlphaType);
On 2016/06/29 15:10:33, jbroman wrote:
> Replied offline with questions about the use of kBGRA_8888_SkColorType here.

Changed to kN32_SkColorType, will have another CL to change the constructor that
takes ImageData.

[jbroman, 2016-06-29 18:03:54]

Okay, LGTM (with comments).

Please do find time to double-check that things work correctly on Android at
some point (due to the RGBA/BGRA difference on that platform).

https://codereview.chromium.org/2039983002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.h (right):

https://codereview.chromium.org/2039983002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/bindings/core/v8/ScriptValueSerializer.h:512: bool
doReadImageDataProperties(uint32_t*, uint32_t*, uint32_t*);
Please name parameters here as well; it's not obvious what they are.

https://codereview.chromium.org/2039983002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.cpp (right):

https://codereview.chromium.org/2039983002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.cpp:263: SkImageInfo info =
SkImageInfo::Make(width, height, kN32_SkColorType, isImageBitmapPremultiplied ?
kPremul_SkAlphaType : kUnpremul_SkAlphaType);
super-nit: this can be written slightly shorter:

SkImageInfo info = SkImageInfo::MakeN32(width, height,
isImageBitmapPremultiplied ? kPremul_SkAlphaType : kUnpremul_SkAlphaType);

Doesn't really matter, but there are some convenient shortcuts for N32 and
N32Premul.

https://codereview.chromium.org/2039983002/diff/140001/third_party/WebKit/Sou...
File third_party/WebKit/Source/core/frame/ImageBitmap.h (right):

https://codereview.chromium.org/2039983002/diff/140001/third_party/WebKit/Sou...
third_party/WebKit/Source/core/frame/ImageBitmap.h:98:
ImageBitmap(std::unique_ptr<uint8_t[]>, uint32_t, uint32_t, bool, bool);
Please give the parameters names here as well.

[xidachen, 2016-07-01 00:55:21]

haraken@: gentle ping. Please take a look at bindings/ changes.

[haraken, 2016-07-01 00:56:58]

On 2016/07/01 00:55:21, xidachen wrote:
> haraken@: gentle ping. Please take a look at bindings/ changes.

Sorry, I missed this one. LGTM.

[xidachen, 2016-07-01 01:01:47]

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

[commit-bot: I haz the power, 2016-07-01 01:02:14]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-01 02:17:12]

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

[commit-bot: I haz the power, 2016-07-01 02:17:13]

Dry run: This issue passed the CQ dry run.

[xidachen, 2016-07-01 17:05:50]

The CQ bit was checked by xidachen@chromium.org

[xidachen, 2016-07-01 17:05:51]

The patchset sent to the CQ was uploaded after l-g-t-m from jbroman@chromium.org
Link to the patchset: https://codereview.chromium.org/2039983002/#ps160001
(title: "more comments")

[commit-bot: I haz the power, 2016-07-01 17:06:09]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-07-01 17:10:33]

Description was changed from

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we read the pixel
data according to whether the ImageBitmap is premultiplied or not,
also we store the information whether the bitmap is premultiplied or 
not. When de-serialization happens, we design a new ImageBitmap
constructor specifically for it.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
==========

to

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we read the pixel
data according to whether the ImageBitmap is premultiplied or not,
also we store the information whether the bitmap is premultiplied or 
not. When de-serialization happens, we design a new ImageBitmap
constructor specifically for it.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
==========

[commit-bot: I haz the power, 2016-07-01 17:10:34]

Committed patchset #9 (id:160001)

[commit-bot: I haz the power, 2016-07-01 17:13:27]

Description was changed from

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we read the pixel
data according to whether the ImageBitmap is premultiplied or not,
also we store the information whether the bitmap is premultiplied or 
not. When de-serialization happens, we design a new ImageBitmap
constructor specifically for it.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172
==========

to

==========
Change code path for structured cloning ImageBitmap

This is how it works currently:
When an ImageBitmap is un-premultiplied, we read bitmap's pixel data in
premultiplied format. When de-serialize happens, we call
ImageBitmap::create(ImageData*) and in that create() function, we create
an SkImage that is in premultiplied format because the input data is
already premultiplied. This is causing the problem because the SkImage
should be in un-premultiplied format.

We change the implementation like this:
When we serialize the ImageBitmap into uint8_t*, we read the pixel
data according to whether the ImageBitmap is premultiplied or not,
also we store the information whether the bitmap is premultiplied or
not. When de-serialization happens, we design a new ImageBitmap
constructor specifically for it.

Notice that after this change, the layout tests
fast/canvas/webgl/texImage-imageBitmap-structured-clone.html
passes.

BUG=615172

Committed: https://crrev.com/58c08f3acefbd7a44387d03237967a4644130c0f
Cr-Commit-Position: refs/heads/master@{#403475}
==========

[commit-bot: I haz the power, 2016-07-01 17:13:28]

Patchset 9 (id:??) landed as
https://crrev.com/58c08f3acefbd7a44387d03237967a4644130c0f
Cr-Commit-Position: refs/heads/master@{#403475}