- From: Robert O'Callahan <robert@ocallahan.org>
- Date: Tue, 18 Oct 2011 15:38:26 +1300
- To: Chris Rogers <crogers@google.com>
- Cc: public-audio@w3.org, Alistair MacDonald <al@signedon.com>
- Message-ID: <CAOp6jLb=_8j6FbRZ56vOG5vrVB2jt3zL3NO64fZ1Vx8ROHK39Q@mail.gmail.com>
On Tue, Oct 18, 2011 at 2:36 PM, Chris Rogers <crogers@google.com> wrote: > Let me try an analogy here. In the graphics world we have distinct > entities such as <img>, <canvas>, <svg>, <video>, ..., and different > JavaScript APIs for dealing with these objects. For <canvas> there are two > different APIs for drawing: canvas 2D, and WebGL. In canvas 2D there's an > entity called ImageData which has a relationship with <img> and WebGL > textures. Canvas 2D has other kinds of objects which manipulate pixels. > All of these APIs and objects have relationships with one another, and can > be used together to great effect. Then there's CSS which describes > structural relationships, etc. So there are many different types of objects > which each have targeted APIs that can work well together. There is no > one-size-fits-all abstraction for dealing with graphics, and there shouldn't > be. > <img> is an HTML element containing a read-only image in some unknown format. <canvas> is an HTML element containing a mutable image in some unknown format. <svg> is an XML element which is the parent for a DOM subtree representing vector graphics. <video> is an HTML element responsible for loading and playing a media resource with video. CanvasRenderingContext2D contains 2D drawing state --- current transform, current clip, etc. WebGLContext contains OpenGL drawing state. ImageData is a non-DOM object representing an array of RGBA pixel values. All of those things represent different abstractions with different internal state. In most cases it doesn't make sense to put them behind the same abstraction because they represent very different things. <img>, <canvas> and <video> do have some commonality, for example they can all be styled with CSS, and we do put them behind the same abstraction: they're all HTML elements and subclasses of HTMLElement. This is the approach I've taken with the Web Audio API. I can't say that > the API or the implementation is perfect, but it's very much more than a > prototype at this point and I sincerely hope that people will consider it > seriously. In terms of maturity, the API itself has undergone lots of > scrutiny over a period of more than a year. It has working implementations > in multiple browsers on multiple platforms, > Multiple browsers on multiple platforms, definitely, but there's really only one implementation: yours. Rob -- "If we claim to be without sin, we deceive ourselves and the truth is not in us. If we confess our sins, he is faithful and just and will forgive us our sins and purify us from all unrighteousness. If we claim we have not sinned, we make him out to be a liar and his word is not in us." [1 John 1:8-10]
Received on Tuesday, 18 October 2011 02:38:55 UTC