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

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?

On Thu, Apr 9, 2015 at 10:50 PM, Robert O'Callahan <robert@ocallahan.org>
wrote:

> On Fri, Apr 10, 2015 at 12:23 PM, Kenneth Russell <kbr@google.com> wrote:
> >
> > 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?
> >
>
> Yes, if the new ImageBitmap has a different size to the old one (if any).
>
> 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?
> >
>
> Yes, but only if the image element has CSS 'width' or 'height' 'auto'.
>
> If you use an HTMLImageElement with auto width or height, then the size of
> the element will depend on the size (or aspect ratio) of the ImageBitmap
> you put into it. If that size changes, layout will have to occur. This is a
> feature, not a bug. It shouldn't come as a surprise that if you don't want
> layout to occur, you need to ensure the HTMLImageElement keeps the same
> size, by using same-sized ImageBitmaps (the common case, I guess, when the
> page is placing a series of images into the same element), or using CSS
> 'width' and 'height' to size the element.
>
> 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?
> >
>
> AFAICT, in practice the difference is that with the HTMLCanvasElement
> approach, missing 'width'/'height' attributes default to 300x150, whereas
> with the HTMLImageElement approach missing 'width'/'height' attributes (and
> CSS properties) default to a size based on the size of the ImageBitmap.
>
> So is your argument that the HTMLCanvasElement approach is better because
> authors will immediately notice that leaving out 'width' and 'height'
> attributes breaks their page, and thus will never forget to supply those
> attributes, whereas with HTMLImageElement authors might leave out 'width'
> and 'height', still get good results but incur a hidden performance
> penalty?
>
> 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 14:18:27 UTC