Bug 39177

Summary: Canvas 2d globalCompositeOperation source-in, source-out, destination-in, destination-atop, darker and copy are broken
Product: WebKit Reporter: Stefan Wehrmeyer <stefanwehrmeyer>
Component: CanvasAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: benwells, chuck, hamaji, imgroxx, jchaffraix, jiminizer, kangax, mdelaney7, mike, oliver, VYV03354
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: All   
OS: All   
URL: https://developer.mozilla.org/samples/canvas-tutorial/6_1_canvas_composite.html
Attachments:
Description Flags
reference rendering with wrong renderings marked red none

Stefan Wehrmeyer
Reported 2010-05-16 07:42:51 PDT
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.
Attachments
reference rendering with wrong renderings marked red (26.78 KB, image/png)
2010-05-16 07:42 PDT, Stefan Wehrmeyer 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Oliver Hunt
Comment 1 2010-07-08 11:34:49 PDT
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
Comment 2 2010-07-08 11:35:08 PDT
(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
Comment 3 2010-08-16 03:25:16 PDT
*** Bug 34027 has been marked as a duplicate of this bug. ***
Charles Pritchard
Comment 4 2010-11-27 11:42:38 PST
(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
Comment 5 2010-11-27 15:14:31 PST
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
Comment 6 2011-04-28 19:32:41 PDT
Oliver, your thoughts on this?
Julien Chaffraix
Comment 7 2011-05-05 11:56:09 PDT
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
Comment 8 2011-08-02 04:32:03 PDT
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
Comment 9 2011-08-22 23:21:44 PDT
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 ***
Note You need to log in before you can comment on or make changes to this bug.