Re: A few comments on the custom shaders spec

Hi Rob,

On Mar 10, 2013, at 2:40 PM, Robert O'Callahan <robert@ocallahan.org> wrote:

>> On Fri, Mar 8, 2013 at 5:54 PM, Dirk Schulze <dschulze@adobe.com> wrote:
>> The section "Fragment Shaders Differences with GLSL"[1] describes the security steps Shaders need to take to fulfill this requirement:
>> 
>> ""
>> A normal GLSL shader requires that the fragment shaders computes a gl_FragColor value which is the color value for the processed fragment (pixel).
>> Because of the security restrictions, fragment shaders are not allowed to access rendered content pixel values directly.
>> ""
> 
> I'm afraid that isn't nearly precise enough.

Ok, thank you very much for your input. Can you give more details what should be specified more? Maybe you have some suggestions for this section? I would really appreciate your input.

>  
>> > I thought that to compensate for the lack of access to rendered content, we were going to allow fragment shaders to generate a per-pixel color matrix which would then be applied to the content. But I don't see any sign of that. Is that coming?
>> 
>> In the same section "Fragment Shaders Differences with GLSL"[1] it is defined how to influence pixel colors.
> 
> OK, I missed that somehow, sorry... Thanks.
> 
>> > Section 17.2 is totally unclear. In particular, what does "input" mean here? I thought the whole point of section 17.1 was to eliminate the need to track the origins of rendered content.
>> 
>> In the last WD it was possible to pass a previous filter primitive result as texture parameter into the shader (as secondary input) under the condition that it is not the direct or indirect result of the pages web content. This requires tracking which filter primitive counts as "dirty". I removed it in this version. I am looking forward to add it again to allow generators like feTurbulence as input.
> 
> OK but the language in section 17.2 needs to be clarified.

This subsection is relevant for other specifications like CSS Masking and SVG2 too. One of the main reason that this section in Filter Effects and other specifications is the behavior of Firefox. Can you provide more details when Firefox relies on CORS for resources and how? What is missing in the specification text?

Thanks a lot!

Greetings,
Dirk

> 
> Rob
> -- 
> Wrfhf pnyyrq gurz gbtrgure naq fnvq, “Lbh xabj gung gur ehyref bs gur Tragvyrf ybeq vg bire gurz, naq gurve uvtu bssvpvnyf rkrepvfr nhgubevgl bire gurz. Abg fb jvgu lbh. Vafgrnq, jubrire jnagf gb orpbzr terng nzbat lbh zhfg or lbhe freinag, naq jubrire jnagf gb or svefg zhfg or lbhe fynir — whfg nf gur Fba bs Zna qvq abg pbzr gb or freirq, ohg gb freir, naq gb tvir uvf yvsr nf n enafbz sbe znal.” [Znggurj 20:25-28]

Received on Monday, 11 March 2013 02:53:16 UTC