- From: Charles Pritchard <chuck@jumis.com>
- Date: Mon, 17 Jan 2011 13:50:24 -0800
On 1/17/2011 1:47 PM, Robert O'Callahan wrote: > On Wed, Jan 5, 2011 at 12:05 PM, <carol.szabo at nokia.com > <mailto:carol.szabo at nokia.com>> 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
Received on Monday, 17 January 2011 13:50:24 UTC