Since Jan 5 I have refined my proposal. It now looks like this: I propose changing the drawing model steps 2 to 5 the following way:
Step 2: Multiply the alpha channel of every pixel in A by globalAlpha. (Prior Step 5) Step 3: When shadows are drawn<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn>, render the shadow from image A, using the current shadow styles, creating image B. Step 4: When shadows are drawn<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn>, composite image B onto image A using destination-over compositing operation. This algorithm is less expensive then the prior one (it saves one multiplication of the AlphaChannel over the entire B bitmap), and treats the image/object drawn and its shadow as one entity. Which results in the shadow being preserved for composite operations such as copy and source-in and produces less strange results in operations such as xor and destination-out when shadows are drawn. The this algorithm yields the same result as the current version of the spec for source-over, but for completeness supports shadows in all modes. Indeed the way the current spec exists, many non-source-over modes including xor yield very strange results if shadows are used. I do not care that much if the spec has my proposal in it or whether it specs that shadows are not rendered in modes other then source over, but it would be nice to hear an agreement from browser implementors on this. Carol ________________________________ From: ext Charles Pritchard [[email protected]] Sent: Monday, January 17, 2011 4:50 PM To: [email protected] Cc: Szabo Carol (Nokia-MS/Boston); [email protected] Subject: Re: [whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property - Drawing model discussion On 1/17/2011 1:47 PM, Robert O'Callahan wrote: On Wed, Jan 5, 2011 at 12:05 PM, <[email protected]<mailto:[email protected]>> wrote: Given the statements above I no longer think that changing the spec in this regard is a good thing, but I still believe that the disappearance of shadows for the source-in and copy modes and the strange result when shadows are drawn and the composite operation is source-out should be corrected. To do this I suggested the following in my previous e-mail, but I got no comments about my suggestion so I repeat it here (please excuse my insistence): Replace steps 3 to 6 of the drawing model, with: 3. When shadows are drawn<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#when-shadows-are-drawn>, composite B (source) with A (destination) using destination-over operation. 4. Multiply the alpha component of every pixel in A by globalAlpha<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-globalalpha>. 5. Composite A within the clipping region<http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#clipping-region> over the current canvas bitmap using the current composition operator. That might work. However, I have an alternative proposal: if we don't have good use cases for using shadows with non-"source-over" operators (I don't), let's just say that shadows don't draw for non-"source-over" operators. That would reduce spec and implementation complexity. I stay away from shadows. That said, I'd imagine they'd still be used for operations like xor and lighter, where you're "punching through" the bitmap to expose something underneath, or you're blending with the existing bitmap, to display something with the lighter. Not my use case, but I could see it happening. -Charles
