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

On Oct 17, 2011, at 5:36 PM, noam.rosenthal@nokia.com wrote:

> 
> ________________________________________
> 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.

I'm having trouble understanding why this would be. How does whether or not the shader is writing any non-opaque alpha values affect how it is managed WRT its ancestors? And when you say "forces us to use FBOs", do you mean for the CSS-shaded element or its ancestors? I think the CSS-shaded element will always need a "hardware layer" (FBO). And how that layer is composited with its ancestors is platform dependent. For instance, we will always use hardware-based ancestors for a hardware-based element. But again, I don't see how the presence of opacity in the CSS-shaded element affects this. Is there an optimization I'm not seeing?

-----
~Chris
cmarrin@apple.com

Received on Tuesday, 18 October 2011 16:18:28 UTC