[whatwg] Canvas Proposal: aliasClipping property
chuck at jumis.com
Fri Oct 16 09:47:11 PDT 2009
On 10/16/09 8:01 AM, Philip Taylor wrote:
> Windows, Opera 10 passes them all, Firefox 3.5 passes all except
> 'copy' (https://bugzilla.mozilla.org/show_bug.cgi?id=366283), Safari 4
> and Chrome 3 fail them all.
I've read that this was intentional on the part of WebKit.
> (Looking at the spec quickly now, I don't see anything that actually
> states this explicitly - the only reference to infinite transparent
> black bitmaps is when drawing shadows. But
Then, should we explicitly state it, so that the next versions of Chrome
are pressured to follow?
I agree, that the spec has an infinite bitmap for filters: shadows are a
in the rendering pipeline.
In regard to this: 'There is currently no definition of what the
"extent" of a shape is'
While I want a common standard, and I think we are in agreement here,
be defining Image A as an infinite bitmap, I believe that this statement
should be addressed.
The extent of the shape is geometric, it's a rectangle, and it's not
related to the fill [re: transparent pixels].
It can be calculated for an ellipse and for an arbitrary path and
extended to include a shadow, should one exist.
With multiple sub-paths, the extent encompasses all of the subpaths.
The only difficulty in implementation that I see is with text:
TextMetrics does not currently supply a height value, for reasons
unknown to me.
It's quite possible to calculate the extent of a text box, and is
present in many APIs.
Extents are usually calculated within the rendering engine,
and so it's likely that optimizations can be made there, for the
so that it's unnecessary to compare pixels outside of the shape extent
regardless of the spec. But, I am certain that the WebKit devs decided
be more efficient, just as they made similar decision in their aliasing
method on clipped paths.
If my statements are factually inaccurate, I'm sure someone on this list
will take notice, and correct me.
More information about the whatwg