Re: [whatwg] Canvas image to blob/dataurl within Worker

On Fri, Apr 10, 2015 at 2:33 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Sat, Apr 11, 2015 at 2:18 AM, Justin Novosad <junov@google.com> wrote:
>>
>> Riddle me this: What would be the value an HTMLImageElement's src
>> attribute
>> after an ImageBitmap is transferred in? A data URL? What if the
>> ImageBitmap
>> was sourced from an actual resource with a URL, would we pipe that
>> through?  In cases where there is no tractable URL (ex: ImageBitmap was
>> grabbed fram a tainted canvas), then what?
>
>
> We have the same issue for HTMLMediaElement.srcObject:
> http://dev.w3.org/2011/webrtc/editor/archives/20140619/getusermedia.html#widl-HTMLMediaElement-srcObject
> The current approach is to leave 'src' unchanged, and the spec says that if
> there is a current srcObject (or ImageBitmap in our case), render that and
> ignore 'src'.

Here are some more questions, some of which are from a colleague. I'm
not trying to claim credit for thinking of them, but want to make it
clear that there are several more ambiguities with attempting to use
an image element to display ImageBitmaps.

Suppose src="myimage.png" is set on an image element and then, while
it is downloading, an ImageBitmap is transferred into it.

1. What is displayed in the webpage as myimage.png is downloading?
2. Do the downloaded bits overwrite what you transferred or do we stop
the download?
3. Are onload and onerror events fired? This question applies both to
the in-progress download and to the transferred-in ImageBitmap.
4. What should the 'complete' property and 'currentSrc' attribute reflect?
5. Can the developer go back to having the img element contain what
was set on 'src' and not what was transferred in?

srcset and the picture element make the situation even more complex.

In comparison, displaying ImageBitmaps with a custom canvas context
offers simple semantics and avoids other problems raised on this
thread like requiring a layout, or firing events, upon recipt of a new
ImageBitmap.

-Ken

Received on Saturday, 11 April 2015 01:49:50 UTC