The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3b51eab2fb669abcba221346fe7dc03eeb4c6961

commit 3b51eab2fb669abcba221346fe7dc03eeb4c6961
Author: xidachen <xidachen@chromium.org>
Date: Fri Aug 05 15:20:10 2016

Add more layout tests for createImageBitmap with resize options

This CL adds more layout tests under fast/canvas/webgl/ dir to test
createImageBitmap API with resize and other options such as flipY and
premultiplyAlpha=false, to make sure that the behavior of resize is
correct.

TBR=junov@chromium.org
BUG= 632349 

Review-Url: https://codereview.chromium.org/2218963002
Cr-Commit-Position: refs/heads/master@{#410063}

[add] https://crrev.com/3b51eab2fb669abcba221346fe7dc03eeb4c6961/third_party/WebKit/LayoutTests/fast/canvas/webgl/texImage-imageBitmap-from-blob-resize.html
[add] https://crrev.com/3b51eab2fb669abcba221346fe7dc03eeb4c6961/third_party/WebKit/LayoutTests/fast/canvas/webgl/texImage-imageBitmap-from-canvas-resize.html
[add] https://crrev.com/3b51eab2fb669abcba221346fe7dc03eeb4c6961/third_party/WebKit/LayoutTests/fast/canvas/webgl/texImage-imageBitmap-from-image-resize.html
[add] https://crrev.com/3b51eab2fb669abcba221346fe7dc03eeb4c6961/third_party/WebKit/LayoutTests/fast/canvas/webgl/texImage-imageBitmap-from-video-resize.html

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The real situation is a little more complicated, because we have cropping and
resizing together. The current logic uses the following order:

- crop (and color convert) over ImageData
- create SkImage
- down scale the image if needed
- flip the image if needed
- up scale the image is needed

This indeed suffers from a duplicate copy, but I assume the memory will get
released as soon as we exit the function and the primary SkImage goes out of
scope. I don't think this worths to implement another version of scaling that
will be a headache to keep in sync with Skia scale algorithms.

There are two other things that we probably can do to improve the situation
though. First, SkImage is immutable, so if we create an SkImage from the user
buffer, the buffer won't get altered down the way. However, I'm not sure if we can do
that without transferring the sole ownership to SkImage. I'll investigate this.

A probably better solution is to rewrite the scaling code to use SkPixmap
instead of SkImage. I'll investigate this after the first solution since it
requires more change in the code.

Discussed this with mtklein@ form Skia team. According to mtklein@, "there's no way to make an image that does not own its pixels". We of course can set the release proc to no-op, but in this case we need to guarantee that the buffer outlives the SkImage object. This seems to be not straightforward since, according to mtklein@, "the image will sometimes be ref'd by Skia itself for arbitrary amounts of time, particularly in Ganesh", which will extend the image life span in different scenarios.

Flagging this bug as a won't fix.

I still think you were on to something in Comment 7, about using SkPixmap routines.  

SkPixmaps are essentially a thin ownership-agnostic wrapper over a pointer to bytes... you should probably be able to take an input buffer, scale it to the right size (new allocation, obviously), do any other manipulation you need in place, and then only when done pass those pixels off to an SkImage, using SkImage::MakeFromRaster() to transfer ownership to the SkImage.

(Or did I misunderstand what you're doing?)

This is what I do now. The thing is that I'm creating a copy of the buffer passed by user in https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/imagebitmap/ImageBitmap.cpp?q=imagebitmap&sq=package:chromium&dr=CSs&l=629.
If any of color conversion, scaling, alpha multiplying or flipping is asked by the user for ImageBitmap, then it is mandatory to create a copy. The question is, if none of the above is needed, can we use the passed buffer to create the SkImage that serves as the pixel storage for image bitmap?

Looking at the code a little bit more, I think even if Skia allows that, this is still wrong. AFAIK ImageBitmap object is not supposed to change after creation, but it will if we back it by the user buffer and the user decides to change the content of the buffer after creating the ImageBitmap.

Ah, ok.  Yes, unless you can guarantee the pixels won't change, we have to copy them.