[whatwg] Canvas: clarification of compositing operations needed
david at davidflanagan.com
Wed Jul 28 15:12:50 PDT 2010
Tab Atkins Jr. wrote:
> On Wed, Jul 28, 2010 at 2:43 PM, David Flanagan <david at davidflanagan.com> wrote:
>> Firefox and Chrome disagree about the implementation of the
>> destination-atop, source-in, destination-in, and source-out compositing
>> operators. Test code is attached.
>> Chrome doesn't touch any destination pixels that are not underneath the
>> source pixels. Firefox, on the other hand, treats the entire canvas (inside
>> the clipping region) as the destination and if you use the destination-in
>> operator, for example, will erase any pixels outside of whatever you are
>> I suspect, based on the reference to an "infinite transparent black bitmap"
>> in 18.104.22.168.13 Drawing model that Firefox gets this right and Chrome gets it
>> wrong, but it would be nice to have that confirmed.
>> I suggest clarifying 22.214.171.124.3 Compositing to mention that the compositing
>> operation takes place on all pixels within the clipping region, and that
>> some compositing operators clear large portions of the canvas.
> The spec is completely clear on this matter - Firefox is right,
> Chrome/Safari are wrong. They do it wrongly because that's how
> CoreGraphics, their graphics library, does things natively.
Thanks for the confirmation and the explanation of why webkit gets it
I disagree that the spec is completely clear, however. In order to
understand it you have to skip from section 3 on compositing operators
to section 13 which mentions the infinite bitmap and compositing within
the clipping region. There is no mention of the relevance of the
clipping region in the section on compositing which seems like an oversight.
Also, descriptions of the operators cover only transparent and opaque
pixels; they don't explain how compositing is done for translucent
pixels, except by oblique reference to the Porter-Duff paper.
More information about the whatwg