[Public WebGL] Compositing with HTML

Tim Johansson [email protected]
Wed Jan 13 12:45:28 PST 2010

On 2010-01-09 03:45, Philip Taylor wrote:
> On Sat, Jan 9, 2010 at 2:26 AM, Chris Marrin<[email protected]>  wrote:
>> I'm confused.  Clamping to 1 doesn't guarantee that it's a legal
>> premultiplied color, does it?  Or are you saying that the 2d canvas, svg and
>> css take non-premultiplied colors as input, clamp all the channels to 1 and
>> convert them to pre-mulitplied behind the scenes?
>> I'm not sure what they actually do, but I know that the spec says 3 useful
>> things:
>> [...]
>> 2) Colors in the buffer (when read back) are premultiplied
> Where do you see this? getImageData explicitly says "Pixels must be
> returned as non-premultiplied alpha values". The conceptual model
> intended throughout the whole 2d context is that colours are
> non-premultiplied [0, 1] RGBA values - an implementation is free to
> store premultiplied values internally, but that's invisible to the API
> (except via the loss of precision). Some implementations, e.g. Opera's
> (at least in the past), store non-premultiplied values internally and
> never have to do conversions (though it'll need more multiplications
> for its Porter-Duff operators).
Yes, the 2d context treats all in and out data as non premultiplied. In 
WebGL we cannot do the same thing as the author has more direct control 
over the blend functions. Current Opera versions store the 2d canvas 
pixels as non premultiplied (it is changed in the early 10.5 builds) and 
does the porter-duff blends with unpremultiplied values, unfortunately 
opengl lacks the blend modes to implement that so we need to expose 
premultiplied alpha in the API to be able to do porter-duff operations 
and generate an image which can be composited correctly with the page.

You are currently subscribe to [email protected]
To unsubscribe, send an email to [email protected] with
the following command in the body of your email:

More information about the public_webgl mailing list