- From: <carol.szabo@nokia.com>
- Date: Mon, 3 Jan 2011 18:25:16 +0000
I thought that the issue was settled as well, but after talking to Ian Hixie and Philip Taylor, Ian indicated that if someone provides a clear formulation of the spec text that matches webkit behavior, the spec would likely be changed to match that. I have proposed the changes below, but got no reply (or if I got any I missed them): TML5 - Canvas. I have read this thread (from and of July 2010) and I happen to agree that the Safari/Chromium implementation is more intuitive, and likely less expensive to implement, therefore I offer these 2 proposals for changing the spec's Drawing model section to match what I perceive to be the preference of most people in that discussion. Of note: According to the current Drawing model, an opaque shape's shadow would be erased as part of step 6 when drawn with source-in composite Mode if globalAlpha is 1, which is probably not the intended behavior. Version 1: 4.8.11.1.13 Drawing model When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do): 1. Render the shape or image onto an infinite transparent black bitmap, creating image M1, as described in the previous sections except that for the purpose of this step every pixel of the image will be considered to be fully opaque white and the current fillStyle will be considered to be solid fully opaque white and the strokeStyle will be considered fullyOpaque white as well. 2. When shadows are drawn, render the shadow from image M1, using a fully opaque white shadow color as described in the shadows section, creating image M2. 3. Let C1 be a region obtained by intersecting the canvas's cliping region with the set of pixels in the canvas that correspond to pixels in M1 (by having the same coordinates) that are not fully transparent. 4. Let C2 be a region obtained by intersecting the canvas's cliping region with the set of pixels in the canvas that correspond to pixels in M2 (by having the same coordinates) that are not fully transparent. 5. Render the shape or image onto an infinite transparent black bitmap, creating image A, as described in the previous sections. For shapes, the current fill, stroke, and line styles must be honored, and the stroke must itself also be subjected to the current transformation matrix. 6. When shadows are drawn, render the shadow from image A, using the current shadow styles, creating image B. 7. When shadows are drawn, multiply the alpha component of every pixel in B by globalAlpha. 8. When shadows are drawn, composite B with the current canvas bitmap, cliping results to region C2 defined above, using the current composition operator. 9. Multiply the alpha component of every pixel in A by globalAlpha. 10. Composite A with the current canvas bitmap, cliping results to region C1 defined above, using the current composition operator. Version 2: 4.8.11.1.13 Drawing model When a shape or image is painted, user agents must follow these steps, in the order given (or act as if they do): 1. Render the shape or image onto an infinite transparent black bitmap, creating image A, as described in the previous sections. For shapes, the current fill, stroke, and line styles must be honored, and the stroke must itself also be subjected to the current transformation matrix. 2. When shadows are drawn, render the shadow from image A, using the current shadow styles, creating image B. 3. When shadows are drawn, multiply the alpha component of every pixel in B by globalAlpha. 4. When shadows are drawn, composite, using the current composition operator, B with the current canvas bitmap, cliping results to the cliping region of the canvas and to the pixels that would have taken the shadow's color if the composition operator would have been source-over and the shadow would have been fully opaque and the globalAlpha would have been 1. 5. Multiply the alpha component of every pixel in A by globalAlpha. 6. Composite, using the current composition operator, A with the current canvas bitmap, cliping results to the cliping region of the canvas and to the pixels that would have taken the shape's or image's pixel color if the composition operator would have been source-over and the image would have been fully opaque, the fillStyle and strokeStyle would have been a solid fully opaque color, and the globalAlpha would have been 1. I also suggest, this change to section 4.8.11.1.3 Compositing: Instead of: The operators in the above list must be treated as described by the Porter-Duff operator given at the start of their description (e.g. A over B). They are to be applied as part of the drawing model, at which point the clipping region is also applied. (Without a clipping region, these operators act on the whole bitmap with every operation.) [PORTERDUFF] Say: The operators in the above list must be treated as described by the Porter-Duff operator [PORTERDUFF] given at the start of their description (e.g. A over B). They are to be applied as part of the drawing model, which also defines the pixels in the canvas that are to be composited. ________________________________ From: whatwg-bounces@lists.whatwg.org [mailto:whatwg-bounces@lists.whatwg.org] On Behalf Of ext Charles Pritchard Sent: Friday, December 31, 2010 8:20 PM To: whatwg Subject: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property Implementation issues with the Drawing Model [1] have been floating around for some time. For whatever reasons, Microsoft is not willing to publicly discuss their issue with the spec, beyond the scant details listed below. That's fine and all.. I'm bringing it to the WHATWG's attention because it seems to me like some of the confusion could be avoided were a "standard" PNG photo available, demonstrating proper behavior. I thought this issue was resolved some time ago, but it keeps coming up. I don't fault anyone, it's a very subtle part of the spec. This reference image helped me communicate with Robert (Mozilla) last year, about the drawing model section. Screen cap: http://imgur.com/zUu66.png Generated from: https://developer.mozilla.org/en/Canvas_tutorial/Compositing Thread: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-December/024316.html There seems to still be some disagreement over composting: https://bugs.webkit.org/show_bug.cgi?id=39177 I thought we had a handle on this, following some slight changes to the spec by Ian: http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2009-October/023706.html Apparently it's not handled yet. Sending out a flare, hoping that we can get this issue put to rest before the next round of major releases. -Charles Below are the only public comments I'm aware of, that MS has posted on the issue: http://lists.w3.org/Archives/Public/public-canvas-api/2010OctDec/0070.html Earlier thread... http://lists.w3.org/Archives/Public/public-canvas-api/2010AprJun/0046.html These comments lack the detail necessary to provide feedback. -------- Original Message -------- Subject: RE: Inconsistent behaviour of globalCompositeOperation property Resent-Date: Wed, 15 Dec 2010 23:47:24 +0000 Resent-From: public-canvas-api at w3.org<mailto:public-canvas-api at w3.org> Date: Wed, 15 Dec 2010 23:45:39 +0000 From: Jatinder Mann <jmann@microsoft.com><mailto:jmann@microsoft.com> To: public-canvas-api at w3.org<mailto:public-canvas-api at w3.org> <public-canvas-api at w3.org><mailto:public-canvas-api at w3.org> We initially felt that the Drawing Model [1], as written in the spec, was incorrectly defined. We have since consulted with many graphics experts, and it appears that the spec as written, and implemented by Firefox and Opera, is the correct definition of Porter-Duff and composition operations, and its behavior is acceptable. Thanks, Jatinder [1] http://dev.w3.org/html5/2dcontext/#drawing-model Jatinder Mann | Microsoft Program Manager | jmann at microsoft.com<mailto:jmann at microsoft.com> From: public-canvas-api-request@w3.org<mailto:public-canvas-api-request@w3.org> [mailto:public-canvas-api-request@w3.org] On Behalf Of Jatinder Mann Sent: Tuesday, May 25, 2010 11:57 AM To: public-canvas-api at w3.org<mailto:public-canvas-api at w3.org> Subject: Inconsistent behaviour of globalCompositeOperation property As we were reviewing the globalCompositeOperation property [1] of the Canvas 2D Context, we have noticed that there is a large inconsistency with the way web browsers implement this property. Firefox 3.6.3 and Opera 10.5 have a similar behaviour that matches the current version of the Canvas 2D Context spec. Chrome 4.1 and Safari 4.0.5 behave similarly to each other, albeit differently from the spec. Today, web developers cannot reliably use this property in designing their webpages due to this interoperability issue. We consider that the Safari implementation of the Drawing Model makes more sense from a web developer point of view. Most of the Canvas APIs are applied to the next primitive being drawn. However, the clipping behavior, as defined in the current Drawing Model [2], affects the current contents of the Canvas outside of the current primitive being drawn. The Safari Drawing Model calls for the clipping region to only affect the current primitive being drawn. We recommend updating the spec to match the Safari Drawing Model. We would like to discuss this area in more detail. Thank you, Jatinder [1] http://dev.w3.org/html5/2dcontext/#compositing [2] http://dev.w3.org/html5/2dcontext/#drawing-model Jatinder Mann | Microsoft Program Manager | jmann at microsoft.com<mailto:jmann at microsoft.com> -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20110103/dababd39/attachment-0001.htm>
Received on Monday, 3 January 2011 10:25:16 UTC