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

On Tue, Apr 14, 2015 at 10:53 PM, Robert O'Callahan
<robert@ocallahan.org> wrote:
> I guess there are really two different sets of use-cases:
> 1) Use-cases where the ImageBitmap is sized to fill a particular area of
> the screen.
> 2) Use-cases where the ImageBitmap is sized subject to some other
> constraints, e.g. you're processing an existing image.
>
> For #2, you want the ImageBitmap's size to be the intrinsic size of the
> element.
>
> For #1, you don't care about having an intrinsic size. Instead the
> element's size is set by CSS and you want the ImageBitmap to fill the
> element, and you want to be able to use renderedPixelWidth/Height to size
> the ImageBitmap. However, for these use-cases I think the behavior
> currently specced in the OffscreenBitmap proposal doesn't make sense:
>   // The ImageBitmap, when displayed, is clipped to the rectangle
>   // defined by the canvas's instrinsic width and height. Pixels that
>   // would be covered by the canvas's bitmap which are not covered by
>   // the supplied ImageBitmap are rendered transparent black.
> I'm not sure what this means now. Suppose the canvas element has CSS
> "width:100px; height:100px" and the canvas rendered size is 200x200. If the
> application creates a 200x200 ImageBitmap and installs it in the canvas, as
> specced isn't this just going to display some 100x100 subrectangle of the
> ImageBitmap, cropping out the rest?

I believe this is *intending* to say that ImageBitmap is just spammed
into a <canvas> directly, matching pixels 1-to-1.  If the ImageBitmap
overflows the <canvas> in some dimension, the extra is discarded; if
it underflows, the underflow is painted transparent black.  CSS has no
effect on this.  This needs to be stated more explicitly, of course.

The idea is that this isn't drawing an image into the canvas, it's
like loading an ImageData.

> What if instead of a new context type, we had a method on the canvas
> element itself to install a new ImageBitmap, which replaces the backbuffer
> and sets the intrinsic size of the canvas element to the ImageBitmap's
> size, so that 'width' and 'height' are thereafter ignored? Then if the
> canvas has non-auto CSS 'width' and 'height', the image buffer will be
> scaled to fit the CSS size and the example above will work as expected. CSS
> object-fit will then also work, so if the ImageBitmap producer lags behind
> canvas resizing for some reason, authors can use object-fit:contain (or
> cover) to display the mis-sized images in a reasonable way. (object-fit is
> also important for the case where a Worker is presenting images through an
> OffscreenCanvas and its image production may lag behind resizing of the
> canvas element on another thread; we can pass the object-fit value through
> to the compositor to ensure the temporary results look OK.)

This works for me; it avoids the author having to coordinate between
scripts and predict the size of the image beforehand.

~TJ

Received on Wednesday, 15 April 2015 16:55:42 UTC