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
On Tue, Apr 14, 2015 at 9:38 PM, Domenic Denicola wrote:
> I also imagine it won't be too hard to spec, as the point of an opaque stream
> type is that most of its methods consist of "magic happens here" (roughly
> speaking).
Well, we also need to ensure that nothing that takes a stream and the
On Wed, Apr 15, 2015 at 1:15 PM, Kenneth Russell wrote:
> If repeatedly transferring ImageBitmaps of the same size into the same
> won't cause repeated re-layouts, that alleviates my concern
> about efficiency of using images as the output path. I expect that a
> single OffscreenCanvas will be u
On Sun, Apr 12, 2015 at 2:41 PM, Robert O'Callahan wrote:
> On Sat, Apr 11, 2015 at 1:49 PM, Kenneth Russell wrote:
>>
>> Suppose src="myimage.png" is set on an image element and then, while
>> it is downloading, an ImageBitmap is transferred into it.
>
>
> This should behave as if "src" was remo
From: whatwg [mailto:whatwg-boun...@lists.whatwg.org] On Behalf Of Anne van
Kesteren
> Well, except now you make yourself depend on some definition of an
> opaque stream object which nobody has defined yet. Perhaps we should,
> but that will take longer and won't be less work (though maybe less w
On Mon, Apr 13, 2015 at 10:34 PM, Matthew Wolenetz wrote:
> Certainly. As I understand it, the reasons for reusing appendStream() rather
> than adding appendResponse() to MSE are generally two-fold:
> a) MSE already has appendStream(). In combination with the other changes to
> Streams API, Fetch,
