W3C home > Mailing lists > Public > www-style@w3.org > October 2011

Re: [css-shaders] Feedback about default fragment shader in CSS shaders proposal

From: Chris Marrin <cmarrin@apple.com>
Date: Mon, 17 Oct 2011 15:36:08 -0700
Message-id: <A976C17F-8C81-4CF5-8BF4-5C78783ABC59@apple.com>
To: www-style list <www-style@w3.org>

On Oct 12, 2011, at 11:10 AM, noam.rosenthal@nokia.com wrote:

> Hi
> I've been following the CSS shader proposal, and am very excited about it.
> I think one tricky issue that we have to figure out ahead of time in that spec is the default shaders, since those shaders are going to be overridden with the default uniform names in mind etc.
> The issue that popped when I saw the default fragment shader is that it doesn't include an opacity uniform. This would mean, that layers with a custom CSS shader plus opacity would have to render the layer into an intermediate buffer (FBO), and then paint them again with opacity. This, in many cases, would be unnecessary overhead.
> Therefore, my proposal for the default fragment shader is something along the lines of:
> varying vec2 v_texCoord;
> uniform sampler2D s_texture;
> uniform float u_opacity;
> void main()
> {  
>     gl_FragColor = texture2D(s_texture, v_texCoord) * u_opacity;
> }

I don't like the idea of including opacity, since I'm sure there are some drivers that would not optimize it out in the presence of an opacity uniform of 1. This also brings up the question of default blend modes and how you change them. By default GL ES will not blend the source pixel with the destination. You have to turn it on using glBlendFunc. On some hardware, blending is expensive because it requires reading the destination pixel.

I think we should err on the side of efficiency and have authors make an explicit shader if they want to include opacity and blending. But that begs the question of how do we turn blending on?

> There is also an issue with making sure those custom shaders are OpenGL ES2 compliant, in essence allowing percision identifiers (lowp/highp), or another strategy to make sure people create shaders that work across GL and GL ES2.

WebGL constrains shaders to the subset of the GLSL ES language that it accepts. All other shaders are rejected. WebGL shaders are a slightly restricted subset of GLSL ES to allow shaders to be parsed and run on top of Direct3D. All of this logic is included in the ANGLE library [1]. It both validates shaders for correctness and translates them to run on top of GLSL ES, GLSL, and HLSL. We can reuse all that logic if we stick with the WebGL subset of GLSL.

[1] http://code.google.com/p/angleproject/

Received on Monday, 17 October 2011 22:36:54 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:50:08 UTC