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

On Fri, Apr 10, 2015 at 12:23 PM, Kenneth Russell <kbr@google.com> wrote:

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

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 02:50:56 UTC