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
