- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Wed, 15 Apr 2015 17:53:50 +1200
- To: Kenneth Russell <kbr@google.com>
- Cc: Justin Novosad <junov@google.com>, Ian Hickson <ian@hixie.ch>, Jake Archibald <jaffathecake@gmail.com>, WHATWG <whatwg@whatwg.org>
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? 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.) 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 Wednesday, 15 April 2015 05:54:14 UTC