[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<firstname.lastname@example.org> wrote: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.
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
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).
You are currently subscribe to email@example.com.
To unsubscribe, send an email to firstname.lastname@example.org with
the following command in the body of your email: