- From: Philip Taylor <excors+whatwg@gmail.com>
- Date: Fri, 16 Oct 2009 13:06:11 +0100
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
Received on Friday, 16 October 2009 05:06:11 UTC