[whatwg] Canvas Proposal: aliasClipping property

[Charles Pritchard]

On 10/15/09 6:37 PM, Ian Hickson wrote:
> On Sat, 3 Oct 2009, Charles Pritchard wrote:
>    
>> I agree it would be good for canvas users to be able to turn off
>> antialiasing in<canvas>. But your syntax is not the best way to do
>>      
> Turning off anti-aliasing just trades one problems for another.
>    
I'm not sure I understand what that trade is -- isn't that something 
that the
individual user of Canvas would take into account when flipping the switch?

I'd thought that implementers would get something of a break, if this toggle
were only applied to clip(), as its somewhat rarely used in the wild 
(unlike say, fill,
and everything around it).

Robert has pointed out that it's the anti-aliasing method that causes 
issues.
> IT seems like what we should really do is either have UAs oversample
> without antialiasing and then downsample for rendering, or, if that is
> considered too expensive, provide primitives that make this a non-problem.
> For example, instead of just having the ability to draw rectangles, maybe
> we need the ability to specify a number of rectangles, and then have them
> all drawn at once, so that if they are adjacent, the UA can render them
> without the anti-aliasing artifacts between them.
>    
As far as I've seen, this issue has only been noticed [in the wild] and 
scorned those
attempting to use clip() in various ways. Though you have put forward a 
novel
alternate proposal.

The setTimeout/setInterval loop (intrinsic to Canvas, via Window... and 
intrinsic to its double-buffering properties)
appropriately segments one set of primitive drawings from another set 
(drawing them all at once).
That particular loop is already setup, browser vendors within the 
current standard could make
appropriate adjustments (turning off coverage based anti-aliasing for 
adjacent lines).

They would have to buffer the fill / fillRect / drawImage commands 
though, to identify when
lines are adjacent.
> In either case, it seems like something best handled in a future version.
>    
It seems like something that won't be handled in this version.

Double buffering seems to be implicit in the docs (certainly talked 
about on this list)
though not explicitly mentioned, so we can't build on it.
...
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.

Best as I can tell, Chrome takes the most efficient approach.

For a very visible example, see the Moz page below in both browsers:
https://developer.mozilla.org/en/Canvas_tutorial/Compositing