W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2011

[whatwg] Fwd: RE: Inconsistent behaviour of globalCompositeOperation property

From: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 4 Jan 2011 11:56:05 +1300
Message-ID: <AANLkTimCMnTSCiAUyspTJzsq-JohtkfaKxZEKE54Zk2t@mail.gmail.com>
On Tue, Jan 4, 2011 at 7:25 AM, <carol.szabo at nokia.com> wrote:

>  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):
>

Sorry, I should have replied earlier.

 HTML5 - 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.
>

Making a binary fully-transparent/not-fully-transparent per-pixel decision
to create regions C1 and C2 seems like it can't be right in the presence of
antialiasing.

Suppose we have a path filled with black and operator "copy". Any pixel on
the edge of that path that gets any nonzero coverage value from antialiasing
will end up solid black with this proposal. That's going to look very ugly.
We'll want a solution where any canvas pixel which has a very small amount
of coverage by the path will be mostly unchanged in the final result.

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
>

Again, this needs to be modified to take into account the possibility that
some pixels are partially covered.

>
Given that Microsoft have indicated they're happy with the current spec, and
are presumably implementing it, I think we should get their explicit
approval before we change the spec here. I'm still happy with either the
current spec or your proposed change (after the issues have been addressed).

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20110104/a305a1f8/attachment-0001.htm>
Received on Monday, 3 January 2011 14:56:05 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:29 UTC