Re: [css-shaders] CSS shaders for custom filters (ACTION-3072)

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:43 UTC