Re: video.getContext

On 3/9/12 7:22 AM, Robert O'Callahan wrote:
>
>     I don't think the image filters WD handles time varying content
>     (i.e. access to past frames), which might be required for some
>     video processing. So having a filter script context along the same
>     lines as the audio context would probably make some sense; CSS
>     application notwithstanding.
>
>
> I have a proposal (and prototype implementation) for an API for 
> processing MediaStreams:
> https://dvcs.w3.org/hg/audio/raw-file/tip/streams/StreamProcessing.html
> It's targeted at audio right now (as an alternative to Chris Rogers' 
> Web Audio API), but designed to extend to video as well. (It's 
> probably not worth adding video processing until we have clear use 
> cases and WebGL support in Workers.)
>
> In general I don't think APIs like canvas's getContext() are a good 
> pattern to follow. It's simpler just to add a named method or 
> attribute for each kind of object that can be returned.

I'd like to see your stream processing proposal used with Canvas 
ImageData at some point.

I've suggested that at some point, CSS shaders may be able to use JS 
workers in addition to their primary target of fragment shaders.
https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/index.html

Your processing API sets up a foundation for it.

The getContext from Canvas has worked well over its lifetime. I wouldn't 
want to apply it to many other elements. Canvas is an area where we've 
been able to replace the <object> tag in some sense. The getContext 
method has helped with that.

-Charles