Re: Rendering on a <canvas>

On 4/30/12 10:57 AM, Anant Narayanan wrote:
> Hi all,
>
> As we try to resolve the <video> assignment issue, I'd like begin the 
> <canvas> discussion in parallel.
>
> I propose that we allow direct assignment of a MediaStream to a 
> <canvas> object, like so:
>
> let stream = [MediaStream obtained by some means]
> let ctx = document.getElementById('canvas').getContext('2d');
> ctx.stream = stream;
>
> If we decide to go with the URL approach for <video> we can change 
> this API to match. The key point though, is to allow a <canvas> to be 
> a *direct* recipient of video data from a MediaStream.
>
> It is possible to do this without explicit support from the 
> getUserMedia spec:
>
> let canvas, video; [DOM objects preset]
> canvas.getContext('2d').drawImage(video, x, y, w, h, offsets...);
>
> However, the developer will have to call drawImage on a DOM timer. It 
> is much more efficient and cleaner for the MediaStream to manipulate 
> the <canvas> directly.
>
> It is a little weird to have a canvas in the DOM changing constantly 
> (at the frame rate of the MediaStream), but I think the benefits 
> outweigh the drawbacks.

We've got requestAnimationFrame to keep in reasonable loop and to 
synchronize the rest of our [canvas] drawing calls.

RoC has proposed that a "stream" object exist with Canvas, but the 
concept is for output, not input -- as part of his media stream 
processing proposal.

I'm all for efficiency, but I do not see what the benefit of using 
Canvas is, if there are no other drawing calls attached.

-Charles

Received on Monday, 30 April 2012 19:04:26 UTC