[whatwg] Canvas Proposal: aliasClipping property

[Ian Hickson]

On Thu, 15 Oct 2009, Charles Pritchard wrote:
> >
> > 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?

Sure, but you're still just trading one problem for another. What if you 
want neither aliasing (i.e. you don't want 1 bit clipping paths) nor the 
problem to which ou allude (i.e. painting can't be done incrementally)?
Surely it's best to solve both problems rather than force authors to pick 
which problem they want.


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

You can't know, in the current setup, which lines are supposed to be 
adjacent and which lines are supposed to be superimposed.


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

Right.


> 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

On Fri, 16 Oct 2009, Philip Taylor wrote:
> 
> 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).

On Sat, 17 Oct 2009, Robert O'Callahan wrote:
>
> Ah, so you mean Firefox is right in this case?

On Fri, 16 Oct 2009, Philip Taylor wrote:
> 
> Yes, mostly. 
> http://philip.html5.org/tests/canvas/suite/tests/index.2d.composite.uncovered.html 
> has relevant tests, matching what I believed the spec said - on 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.
> 
> (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 
> http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-model 
> is phrased in terms of rendering shapes onto an image, then compositing 
> the image within the clipping region, so I believe it is meant to work 
> as I said (and definitely not by compositing only within the extent of 
> the shape drawn onto the image).)

On Fri, 16 Oct 2009, Charles Pritchard wrote:
>
> Then, should we explicitly state it, so that the next versions of Chrome 
> and Safari are pressured to follow?
> 
> I agree, that the spec has an infinite bitmap for filters: shadows are a 
> unique step 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, 
> that we'll be defining Image A as an infinite bitmap, I believe that 
> this statement should be addressed.

On Sat, 17 Oct 2009, Robert O'Callahan wrote:
> 
> That shouldn't be necessary. If the composition operation was limited to 
> the extents of the source shape, the spec would have to say this 
> explicitly and define what those extents are. I don't see how you can 
> argue from silence that the composition operation should be bounded to 
> some unspecified region.

On Sat, 17 Oct 2009, Robert O'Callahan wrote:
> 
> If nothing in the spec depends on a definition of the "extent" of a 
> shape, then the spec should not define it.

On Sat, 17 Oct 2009, Robert O'Callahan wrote:
> 
> I think there is a reasonable argument that the spec should be changed 
> so that compositing happens only within the shape. (In cairo 
> terminology, all operators should be bounded.) Perhaps that's what 
> Safari and Chrome developers want.

On Fri, 16 Oct 2009, Oliver Hunt wrote:
> 
> This is the behaviour of the original canvas implementation (and it 
> makes a degree of sense -- it is possible to fake composition implying 
> an infinite 0-alpha surrounding when the default composite operator does 
> not do this, but vice versa is not possible).  That said I suspect we 
> are unable to do anything this anymore :-/

On Sat, 17 Oct 2009, Robert O'Callahan wrote:
> 
> If Safari and Chrome currently do bound composition to the shape, and 
> always have, then surely it's not too late to spec that?

The problem is in defining what this means, exactly. As Philip` mentioned, 
other browsers do do what the spec says (Opera in particular does a very 
good job).

I've made this more explicit, though.


On Fri, 16 Oct 2009, Robert O'Callahan wrote:
> On Fri, Oct 16, 2009 at 2:37 PM, Ian Hickson <ian at hixie.ch> wrote:
> > 
> > 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.
>
> The latter approach often is not usable in practice when you don't know 
> much about the scene that's being drawn, for example when you're using 
> canvas to implement another drawing API.

Sure. I don't know that we want to be encouraging people to abstract away 
this API even further, though... it's already quite the stack of APIs as 
it is (video driver API, GUI API, platform-independent framework like 
Cairo, internal browser API, JS API...).


On Fri, 16 Oct 2009, Charles Pritchard wrote:
> 
> 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.

We'll be adding this (and many other metrics) once browsers have the 
fundamentals (like globalCompositeOperation) more reliably implemented.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'