Bug 39177 – Canvas 2d globalCompositeOperation source-in, source-out, destination-in, destination-atop, darker and copy are broken

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Canvas

[Stefan Wehrmeyer]

Created attachment 56188 [details]
reference rendering with wrong renderings marked red 

What steps will reproduce the problem?
1. Compare the canvas rendering of
https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html 
to the reference images at 
https://developer.mozilla.org/en/Canvas_tutorial/Compositing

What goes wrong?
The following composite operations do not render as they should, but as the following:
"source-in" renders like "source-atop"
"source-out" renders like "xor"
"destination-in" renders like there was no second drawing (no red circle)
"destination-atop" renders like "destination-over"
"darker" doesn't look like the reference (not sure though if the reference gets the darker color right)
"copy" renders like "source-over"

A reference rendering is attached with buggy compositing operations marked red.

This bug is related to
https://bugs.webkit.org/show_bug.cgi?id=34027
but this is a more complete version of the current canvas compositing bugs.

This bug has also been filed downstream at
http://code.google.com/p/chromium/issues/detail?id=37799

Firefox and Opera currently get most composite operations right. This should be fixed as soon as possible, so developers don't have to write custom code for webkit.

[Oliver Hunt]

We believe the spec is wrong in its definition of these behaviours.  The spec behaviour is inconsistent with the original canvas implementation from webkit, and is less powerful.

[Oliver Hunt]

(In reply to comment #1)
> We believe the spec is wrong in its definition of these behaviours.  The spec behaviour is inconsistent with the original canvas implementation from webkit, and is less powerful.

...
And is slower.

[Shinichiro Hamaji]

*** Bug 34027 has been marked as a duplicate of this bug. ***

[Charles Pritchard]

(In reply to comment #1)
> We believe the spec is wrong in its definition of these behaviours.

I believe the spec has been updated, and Mozilla has changed their behavior in FF4. Case closed?

[Stefan Wehrmeyer]

The behavior of compositing in Webkit is still not compliant to the spec. Firefox and Opera behave the same and as far as I can see compliant to the HTML5 canvas spec.

The "darker" compositing mode is not in the spec, but the description in the bug report still holds. 

I'm the developer of Mapnificent.net and I'm relying on the "destination-in" compositing mode to implement intersections of two areas, see this link (in a Firefox browser) for an example: http://bit.ly/hkqzBN

That doesn't work in Webkit browsers and it is pretty frustrating. I don't know which spec Webkit needs to implement, but I would vote for the HTML5 Canvas spec instead of the original canvas implementation (that might be inconsistent to the current spec). As a developer I want my HTML5 application to work the same across browsers and currently Webkit is the only one stepping out of line.

Please someone confirm this or make a decision.

[kangax]

Oliver, your thoughts on this?

[Julien Chaffraix]

FYI, I posted a patch to correct the source-in and source-out behavior for fillRect as part of bug39027 as FF4, IE9 and Opera all matches the specification and we are the only one standing out.

[Jim]

I'm in the same position as Stefan here. Without destination-in working to specification, my app won't work on Webkit based browsers. The specification still reflects how I believe destination-in should work (show destination only where destination and source overlap) and other browsers implement this correctly.

If the behaviour of the specification is "less powerful" than the webkit implementation, then surely there must at least be a webkit specific way of achieving what is defined in the specification as "destination-in".

[Ben Wells]

All issues reported have been fixed in bug 66036, with the exception of 'darker' which is no longer covered by the canvas spec.

*** This bug has been marked as a duplicate of bug 66036 ***