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

From: Chris Marrin <<>>
Date: Mon, 17 Oct 2011 15:36:08 -0700
To: www-style list <<>>
Subject: Re: [css-shaders] Feedback about default fragment shader in CSS shaders proposal

On Oct 12, 2011, at 11:10 AM,<> wrote:

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?

[vh] I agree that we should not have default uniforms and let people define their shaders if they need that. I have added an issue about turning blending on:


Received on Thursday, 20 October 2011 09:47:06 UTC