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

On Wed, Apr 8, 2015 at 10:29 PM, Robert O'Callahan <robert@ocallahan.org> wrote:
> On Thu, Apr 9, 2015 at 9:44 AM, Kenneth Russell <kbr@google.com> wrote:
>>
>> On Tue, Apr 7, 2015 at 6:42 PM, Robert O'Callahan <robert@ocallahan.org>
>> wrote:
>> > As far as I can tell, the only significant difference between
>> > this and WorkerCanvas is using an HTMLCanvasElement "bitmaprenderer" as
>> > a
>> > zero-copy way to render an ImageBitmap, instead of HTMLImageElement.
>>
>> That's the main difference. Another is that OffscreenCanvas can be
>> directly instantiated from both the main thread and workers.
>
>
> Oh, it was always intended that WorkerCanvas be instantiable from a Worker,
> it just wasn't written down (and "Exposed" hadn't been invented yet :-).)
>
>>
>> >Can you explain what the problem was with using HTMLImageElement?
>>
>> One browser implementer pointed out that HTMLImageElement has several
>> complex internal states related to loading, and they do not want to
>> conflate that with the display of ImageBitmaps. I've documented this
>> in the OffscreenCanvas proposal. (I originally thought Canvas had more
>> complex internal state, but now think that it can be easier to define
>> new behavior against a new canvas context than <img>.)
>
>
> I like your original thought better :-). I don't think circumventing the
> HTMLImageElement states is an issue, in Gecko at least. To me it seems
> desirable for an element displaying an ImageBitmap to get its intrinsic size
> from the ImageBitmap, which fits better with HTMLImageElement than
> HTMLCanvasElement. For example this would make object-fit and
> object-position useful on such elements.

I can't speak for the other implementer. Hopefully they can comment
here; I've pointed them at this thread. Here are a couple of reasons I
now think a new canvas rendering context is a better fit.

It's crucial that displaying a new ImageBitmap be a cheap operation. I
don't understand the HTMLImageElement spec [1] well enough to
understand the implications of transferring in a new ImageBitmap.
Consider these situations:

1. An image element that didn't have a width or height explicitly
specified in the markup has an ImageBitmap transferred in. Will its
width and height attributes change? Will layout have to occur on the
page?

2. The same image element has another ImageBitmap transferred in which
has a different width and height. Do the image's width and height
change? Will layout have to occur on the page?

When an image's src is set to a URL and its width and height
attributes aren't set, the page is laid out again when the image is
loaded. For acceptable performance it's important that this not happen
when displaying a new ImageBitmap. Using a new canvas context type
solves this problem. The OffscreenCanvas proposal defines the
ImageBitmap as being rendered at the upper left corner of the canvas's
box with no scaling applied, and clipped to the box. It's not as
flexible as having the object-fit and object-position CSS properties
available, but will give developers explicit control over when they
want layout to happen, and still let them display their content as
they wish.

Comments?

[1]
https://html.spec.whatwg.org/multipage/embedded-content.html#the-img-element

-Ken


> 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 Friday, 10 April 2015 00:23:57 UTC