[whatwg] Canvas Proposal: aliasClipping property

[Philip Taylor]

On Fri, Oct 16, 2009 at 2:41 AM, Charles Pritchard <chuck at jumis.com> wrote:
> Having gone back and forth with Robert a bit: I was able to recall the whys
> of a particular issue
> that could be handled in this version of the spec, regarding compositing.
>
> As far as I can tell; the area (width and height, extent) of source image A
> [4.8.11.13 Compositing]
> when source image A is a shape, is not defined by the spec.
>
> And so in Chrome, when composting with a shape, the extent of image A is
> only that width
> and height the shape covers, whereas in Firefox, the extent of image A is
> equivalent to the
> extent of image B (the current bitmap). This led to an incompatibility
> between the two browsers.

I think the spec is clear on this (at least when I last looked; not
sure if it's changed since then). Image A is infinite and filled with
transparent black, then you draw the shape onto it (with no
compositing yet), and then you composite the whole of image A (using
globalCompositeOperation) on top of the current canvas bitmap. With
some composite operations that's a different result than if you only
composited pixels within the extent of the shapes you drew onto image
A.

(With most composite operations it makes no visible difference,
because compositing transparent black onto a bitmap has no effect, so
this only affects a few unusual modes.)

There is currently no definition of what the "extent" of a shape is
(does it include transparent pixels? shadows? what about text with a
bitmap font? etc), and it sounds like a complicated thing to define
and to implement interoperably, and I don't see obvious benefits to
users, so the current specced behaviour (using infinite bitmaps, not
extents) seems to me like the best approach (and we just need everyone
to implement it).

-- 
Philip Taylor
excors at gmail.com