ImageBitmap: Change two enum uses.

third_party/WebKit/Source/core/frame/ImageBitmap.cpp

Index: third_party/WebKit/Source/core/frame/ImageBitmap.cpp
diff --git a/third_party/WebKit/Source/core/frame/ImageBitmap.cpp b/third_party/WebKit/Source/core/frame/ImageBitmap.cpp
index cae4fbb1b70f014d4cf0cef8c7a2c51a84d7ff7d..5425fa0b59d2318dbfa060c431ca660f51961001 100644
--- a/third_party/WebKit/Source/core/frame/ImageBitmap.cpp
+++ b/third_party/WebKit/Source/core/frame/ImageBitmap.cpp
@@ -98,7 +98,7 @@ ImageBitmap::ImageBitmap(ImageData* data, const IntRect& cropRect)
     , m_bitmapOffset(IntPoint())
 {
     IntRect srcRect = intersection(cropRect, IntRect(IntPoint(), data->size()));
-    OwnPtr<ImageBuffer> buffer = ImageBuffer::create(data->size(), Opaque, DoNotInitializeImagePixels);
+    OwnPtr<ImageBuffer> buffer = ImageBuffer::create(data->size(), NonOpaque, DoNotInitializeImagePixels);

[xidachen, 2015/10/18 14:08:48]

This part is tricky. It was set to be Opaque on purpose. Because in the
constructor of "UnacceleratedImageBufferSurface" class, the following line:

m_surface = adoptRef(SkSurface::NewRaster(info, Opaque == opacityMode ? 0 :
&disableLCDProps));

takes long time when it is NonOpaque, but takes almost no time when it is set to
Opaque. My opinion on this implementation is that the buffer will be filled in
by the source data later, so it doesn't matter whether it is opaque or
non-opaque at the buffer allocation step. However, this could be wrong.

[jbroman, 2015/10/18 15:44:14]

I'd like Justin's opinion, but it seems to me that this causes the image to have
kOpaque_AlphaType in its SkImageInfo, which shouldn't apply to images that
aren't opaque.

[xidachen, 2015/10/18 15:44:52]

Hmmm, I just found something very strange. With the change that you have in the
"UnacceleratedImageBufferSurface", it won't pass your layout test even if I
change this line to be:

OwnPtr<ImageBuffer> buffer = ImageBuffer::create(data->size(), NonOpaque,
InitializeImagePixels);

[jbroman, 2015/10/18 15:48:00]

Yeah, something fishy is going on (or I'm misunderstanding the ImageData API). I
spent about 30 min on Friday trying to figure out what was going on and why I
got very very wrong values, but I haven't dug any deeper.

[Justin Novosad, 2015/10/19 19:13:20]

I agree that the image buffer should be marked as non-opaque.  This will result
in the newImageSnapshot that is taken below to be marked as non-opaque, which is
conservatively accurate.

     if (!buffer)
         return;