- From: Alex Russell <slightlyoff@google.com>
- Date: Thu, 6 Oct 2011 10:15:49 +0000
- To: Chris Marrin <cmarrin@apple.com>
- Cc: Vincent Hardy <vhardy@adobe.com>, "www-style@w3.org CSS" <www-style@w3.org>, "public-fx@w3.org" <public-fx@w3.org>, SVG WG <public-svg-wg@w3.org>
On Tue, Oct 4, 2011 at 12:51 PM, Chris Marrin <cmarrin@apple.com> wrote: > > On Oct 3, 2011, at 6:51 AM, Vincent Hardy wrote: > > Hello, > > The Filter Effects 1.0 draft contains an open issue about supporting "a > filter primitive that would reference a programmable operation, similar to > an OpenCL kernel or GLSL fragment shader": > > https://dvcs.w3.org/hg/FXTF/raw-file/tip/filters/publish/Filters.html#feCustomElement > > During the last FX task force meeting in Seattle, I got the action to > prepare a detailed proposal for supporting custom filters in the Filter > Effects 1.0 (http://www.w3.org/Graphics/SVG/WG/track/actions/3072). > > The detailed proposal can be found at: > > https://dvcs.w3.org/hg/FXTF/raw-file/tip/custom/index.html > > We (at Adobe) have worked on a prototype implementation. The proposal > reflects the work done on the prototype to get a better understanding of the > various issues involved when using fragment and vertex shaders for custom > effects. It also reflects on the feedback and suggestions of several people, > in particular the co-editors for the proposal, Dean Jackson and Erik > Dahlström. > > This is a very exciting proposal, thanks for the doing it and the > implementation. As editor of the WebGL spec, I'd like to suggest you > rephrase the shading language choice. You mention "OpenGL ES for alignment > with fragment shaders in WebGL". I think it's important to more tightly > specify the language as the exact subset of OpenGL ES that is used in WebGL. A question on this point. Does the current url() rule allow referencing an inline shader definition? e.g.: <script id="vertexshader" type="x-shader/x-vertex"> ... </script> <style> #el { filter(url("#vertexshader"), .... ); } </style> > We've done quite a bit of work to narrow the accepted language to a subset > of OpenGL ES that is appropriate for the web, makes it easier to deal with > the security issues, and makes it possible to implement on top of ANGLE (to > allow WebGL to run on top of Direct3D). Making that clear here allows you to > take advantage of those same features. > Also, why do you just mention fragment shaders? The intent it to adopt both > fragment and vertex shaders from WebGL, right? > Finally, it's good that you include section 6.3 on security. That is > obviously the main sticking point of WebGL, and of WebCL if and when it > becomes available. But I don't think you should characterize Denial of > Service as the only real security concern. WebGL represents the first > exposure of an API of the complexity of OpenGL to the web. GLSL is a > programming language which, unlike JavaScript, executes instructions > directly on the host machine. Exposing this kind of functionality to content > authors is unprecedented, and opens up brand new avenues for malicious > exploits. For that reason these drivers need to be hardened against attacks > like never before. > As you say, this work is ongoing and I believe that WebGL and related > technologies will ultimately be as safe as any that are exposed to the web > today. But we're not there yet, which is why Apple includes the > functionality in its browsers, but leaves it disabled. On desktop it can be > turned on with a developer switch and on iOS it is only available to iAd > developers. > We found that when we shipped WebGL 1.0 we should have erred on the side of > expressing greater concern about these issues, rather than making them an > aside. I think the same is true of CSS Shaders. > I'll have more detailed comments later. I just wanted to mention these high > level issues. > ----- > ~Chris > cmarrin@apple.com > > > >
Received on Thursday, 6 October 2011 10:16:44 UTC