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

On Sun, Apr 12, 2015 at 2:41 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell <kbr@google.com> wrote:
>>
>> Suppose src="myimage.png" is set on an image element and then, while
>> it is downloading, an ImageBitmap is transferred into it.
>
>
> This should behave as if "src" was removed just before the ImageBitmap is
> transferred into it.
>
> In spec terms, I think we'd define a new state flag "has an ImageBitmap".
> Transferring an ImageBitmap into an <img> element would set that flag and
> trigger "update the image data". After step 2 of "update the image data",
> when the flag is set, we'd synchronously do what "update the image data"
> would do with no source: clear "last selected source" (step 4), and do steps
> 9.1 and 9.2 (but never fire the "error" event). Then, transferring the
> ImageBitmap would do the "load complete" work of step 14: set the
> "completely available" state, set the image data, and add the image to the
> list of available images.
>
> Note that this is also exactly what we'd need to do to support srcObject on
> <img>, which would be nice to have so you can render a Blob with an
> HTMLImageElement without dealing with the annoying createObjectURL lifetime
> issues.
>
> Thus:
>
>> 1. What is displayed in the webpage as myimage.png is downloading?
>
>
> As normal before an ImageBitmap is transferred, the ImageBitmap afterward.
>
>> 2. Do the downloaded bits overwrite what you transferred or do we stop
>> the download?
>
>
> 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.
>
>
> No.
>
>>
>> 4. What should the 'complete' property and 'currentSrc' attribute reflect?
>
>
> True and the empty string respectively.
>
>>
>> 5. Can the developer go back to having the img element contain what
>> was set on 'src' and not what was transferred in?
>
>
> As written, yes, by performing another relevant mutation to trigger "update
> the image data" again.
>
>> srcset and the picture element make the situation even more complex.
>
>
> I think the above covers it.

Thanks for these answers.

They sound reasonable to me from a complexity standpoint, though the
needed updates to the <img> tag's spec sound a little involved. I have
another concern which is mentioned below.


>> 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.
>
>
> AFAIK there aren't any issues with events. The issue with layout is simply
> whether or not we want the element receiving an ImageBitmap to have the
> expected intrinsic size. AFAICT for unnecessary layouts to occur would
> require repeated ImageBitmap transfers into the same HTMLImageElement, where
> the ImageBitmaps have varying sizes and the element has auto 'width' or
> 'height', but the author actually intends that the images all be scaled or
> cropped to the same size, and doesn't notice this is not happening. Is there
> a more realistic scenario?

If repeatedly transferring ImageBitmaps of the same size into the same
<img> won't cause repeated re-layouts, that alleviates my concern
about efficiency of using images as the output path. I expect that a
single OffscreenCanvas will be used to produce output to multiple
areas on the page (whether into images or canvases) but that it will
be sized large enough so that all of the ImageBitmaps it produces will
cover the largest of those areas, avoiding repeatedly resizing the
OffscreenCanvas.

There is one other problem which has come up repeatedly in canvas
applications: needing to be able to accurately measure the number of
device pixels covered by a canvas, so pixel-accurate rendering can be
done. https://wiki.whatwg.org/wiki/CanvasRenderedPixelSize addresses
this and it's currently being implemented in Chromium. There is no
such mechanism for images. It would be necessary to understand exactly
how many device pixels the output image is covering in the document so
that the OffscreenCanvas can be sized appropriately. Using a canvas
element for the display of these ImageBitmaps avoids this problem. It
also makes the API more symmetric; a canvas-like object produces the
ImageBitmap, and a canvas element is used to view it. Do you have any
suggestion for how this issue would be solved with <img>?

-Ken

Received on Wednesday, 15 April 2015 01:16:07 UTC