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

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.


> 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?

Rob
-- 
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o
oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofooooolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.

Received on Sunday, 12 April 2015 21:42:10 UTC