[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] Compositing with HTML



On 2010-01-09 03:45, Philip Taylor wrote:
On Sat, Jan 9, 2010 at 2:26 AM, Chris Marrin<cmarrin@apple.com> 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.

//Tim
-----------------------------------------------------------
You are currently subscribe to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email: