[whatwg] Canvas: clarification of compositing operations needed
oliver at apple.com
Wed Jul 28 15:09:22 PDT 2010
On Jul 28, 2010, at 2:46 PM, 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 188.8.131.52.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 184.108.40.206.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.
This is the way the webkit canvas implementation has always worked, firefox implemented this incorrectly, and the spec was based off of that implementation.
Additionally the webkit behaviour is more powerful than the spec behaviour as the spec behaviour can be emulated trivially on top of the webkit model, but vice versa is much harder and much more expensive.
More information about the whatwg