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

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

From: <noam.rosenthal@nokia.com>
Date: Tue, 18 Oct 2011 00:36:50 +0000
To: <cmarrin@apple.com>, <www-style@w3.org>
Message-ID: <9DCC9DB73CE0234F821B00AF47F30CE7A79F61@008-AM1MPN1-026.mgdnok.nokia.com>

From: www-style-request@w3.org [www-style-request@w3.org] on behalf of ext Chris Marrin [cmarrin@apple.com]
> 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?

It's really a trade-off game... The current default shader would force us to use FBOs every time a CSS-shaded element has a semi-transparent ancestor, which is usually much less efficient than an opacity uniform. 
A potentially efficient albeit cumbersome way to fix it, would be to allow people to optionally provide both a blended a non-blended version of their shader, and have the engine use the "blended" version only if the opacity is actually less than one. And by default, if the author only provides one version, we assume that an FBO would be needed if opacity is less than one.

> <snip />
> We can reuse all that logic if we stick with the WebGL subset of GLSL.
Sounds good!

Received on Tuesday, 18 October 2011 00:37:44 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:51 UTC