- From: Kenneth Russell <kbr@google.com>
- Date: Thu, 9 Apr 2015 17:23:31 -0700
- To: "Robert O'Callahan" <robert@ocallahan.org>
- Cc: Jake Archibald <jaffathecake@gmail.com>, Ian Hickson <ian@hixie.ch>, WHATWG <whatwg@whatwg.org>
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