Re: [whatwg] Canvas Proposal: aliasClipping property
On Sat, Oct 17, 2009 at 5:37 PM, Oliver Hunt oli...@apple.com wrote: On Oct 16, 2009, at 8:10 PM, 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. 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). Can't you just clip to the shape? That said I suspect we are unable to do anything this anymore :-/ If Safari and Chrome currently do bound composition to the shape, and always have, then surely it's not too late to spec that? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
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
Re: [whatwg] Canvas Proposal: aliasClipping property
On Fri, Oct 16, 2009 at 2:41 AM, Charles Pritchard ch...@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 exc...@gmail.com
Re: [whatwg] Canvas Proposal: aliasClipping property
On Sat, Oct 17, 2009 at 1:06 AM, Philip Taylor excors+wha...@gmail.comexcors%2bwha...@gmail.com 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. Ah, so you mean Firefox is right in this case? Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
On Fri, Oct 16, 2009 at 2:25 PM, Robert O'Callahan rob...@ocallahan.org wrote: On Sat, Oct 17, 2009 at 1:06 AM, Philip Taylor excors+wha...@gmail.com 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. Ah, so you mean Firefox is right in this case? 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).) -- Philip Taylor exc...@gmail.com
Re: [whatwg] Canvas Proposal: aliasClipping property
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 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. 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 compositing step, so that it's unnecessary to compare pixels outside of the shape extent when compositing, regardless of the spec. But, I am certain that the WebKit devs decided it would 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. -Charles
Re: [whatwg] Canvas Proposal: aliasClipping property
On Sat, Oct 17, 2009 at 5:47 AM, Charles Pritchard ch...@jumis.com wrote: Then, should we explicitly state it, so that the next versions of Chrome and Safari are pressured to follow? 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. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
On Oct 16, 2009, at 8:10 PM, Robert O'Callahan wrote: On Sat, Oct 17, 2009 at 4:01 AM, Philip Taylor excors+wha...@gmail.com 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).) Yes, I think that's pretty clear as written. 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. 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 :-/ Rob --Oliver
Re: [whatwg] Canvas Proposal: aliasClipping property
On Sat, 3 Oct 2009, Charles Pritchard wrote: In some implementations: when drawImage is used along with a clipping path, feathering is applied. This shows up in several projective transformation demos contrasting Firefox with Chrome. [...] On Sun, 4 Oct 2009, Marius Gundersen wrote: [...] it could perhaps include all the other drawing options, like stroking and filling paths created with lineTo, arc, etc. On Thu, 8 Oct 2009, Charles Pritchard wrote: [...] it would work with other things; use a fillRect across the extent of your clipping path. And there you go, aliased paths. On Sun, 4 Oct 2009, Robert O'Callahan wrote: I would just have boolean property named antialias. On Thu, 8 Oct 2009, Charles Pritchard wrote: There are two completely different renderings for various compositon modes in Chrome and Firefox. Chrome developers have certainly posted as to why they chose their method. Firefox devs have certainly taken their stand. I think they're both valid operations, but I'd like to have some unity. [...] On Fri, 9 Oct 2009, Robert O'Callahan 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 that. In particular, this really has nothing to do with clipping, it's all about antialiasing, and a boolean property would be just fine here IMHO. It doesn't matter if canvas currently has no boolean properties, lots of other elements do. Turning off anti-aliasing just trades one problems for another. 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. In either case, it seems like something best handled in a future version. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas Proposal: aliasClipping property
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 incanvas. 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
Re: [whatwg] Canvas Proposal: aliasClipping property
On Fri, Oct 16, 2009 at 2:37 PM, Ian Hickson i...@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. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
My proposal for an aliasClipping property did not get much of a response. I suppose this topic is really one to be mediated between Chrome and Firefox developers, as they have taken two valid approaches to clipping. Marius Gundersen writes: This sounds like a very good proposal, but can we extend it to include other things than just drawImage? I'm not sure how useful it would be, but it could perhaps include all the other drawing options, like stroking and filling paths created with lineTo, arc, etc. To Marius, I responded that indeed it would work with other things; use a fillRect across the extent of your clipping path. And there you go, aliased paths. Robert O'Callahan writes: I think feathered isn't a good term. It's vary rarely used ... I would just have boolean property named antialias. To Robert: As there are no boolean types in the Canvas spec, I thought I'd stick with the current theme, and use a string. Though feathered is rarely used, I don't see why that's much of an issue. To the Entire Group (Please shout at me if you are on a Chrome or Firefox dev-team): I'd like to revise the proposal to again try to mediate the two different clipping methods. I'd certainly like to find a common naming scheme everyone agrees with. I'd like to grow this proposal to encompass the Chrome and Firefox implementations of globalCompositeOperation. There are two completely different renderings for various compositon modes in Chrome and Firefox. Chrome developers have certainly posted as to why they chose their method. Firefox devs have certainly taken their stand. I think they're both valid operations, but I'd like to have some unity. I propose that we add a property (lets find a name): strictClipping = loose (default) | strict. The loose mode being the default, would be exemplified by Mozilla's implementations, and the strict mode is well implemented by Chrome. This would effect clip(), source-in, source-out, destination-atop, and some other composition modes. It would allow us to create aliased paths (via fillRect and clip) as well as add versatility to the composition operators. Most importantly, it would unify Chrome, Firefox and WebKit in their Canvas implementations, in their next release.
Re: [whatwg] Canvas Proposal: aliasClipping property
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 that. In particular, this really has nothing to do with clipping, it's all about antialiasing, and a boolean property would be just fine here IMHO. It doesn't matter if canvas currently has no boolean properties, lots of other elements do. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
Here is a good example of the conflict between Google and Mozilla over clip(): http://www.imperialviolet.org/2009/09/02/anti-aliased-clipping.html There is another conflict, with the composition modes between the two, with Google again taking another principled stand. I'm sorry I don't supporting links for that, but it effects many of the composite operations (at least four of them). I'm hoping to have both methods supported, I think they are both valuable. I've certainly used both methods in my work the past few years. This is very much about the clipping pipeline. -Charles Robert O'Callahan 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 that. In particular, this really has nothing to do with clipping, it's all about antialiasing, and a boolean property would be just fine here IMHO. It doesn't matter if canvas currently has no boolean properties, lots of other elements do. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
On Fri, Oct 9, 2009 at 10:51 AM, Charles Pritchard ch...@jumis.com wrote: Here is a good example of the conflict between Google and Mozilla over clip(): http://www.imperialviolet.org/2009/09/02/anti-aliased-clipping.html There is another conflict, with the composition modes between the two, with Google again taking another principled stand. I'm sorry I don't supporting links for that, but it effects many of the composite operations (at least four of them). I'm hoping to have both methods supported, I think they are both valuable. I've certainly used both methods in my work the past few years. This is very much about the clipping pipeline. No, it is entirely about antialiasing. Coverage-based antialiasing causes problems whenever you draw two objects with adjacent edges that aren't aligned to pixel boundaries. It doesn't matter whether those boundaries are induced by clipping or just by filling a path. The post you linked to even refers to this: The second problem with anti-aliasing, even when done correctly, is that it makes it impossible to put polygons next to each other. Try this demohttp://tulrich.com/geekstuff/canvas/perspective.htmlin Firefox and note the hairlines caused by anti-aliasing. Personally I'm not a big fan of coverage-based antialiasing for exactly this reason, but it's the most common antialiasing technique in graphics libraries so it's hard to get away from. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] Canvas Proposal: aliasClipping property
Robert O'Callahan wrote: On Fri, Oct 9, 2009 at 10:51 AM, Charles Pritchard ch...@jumis.com mailto:ch...@jumis.com wrote: Here is a good example of the conflict between Google and Mozilla over clip(): http://www.imperialviolet.org/2009/09/02/anti-aliased-clipping.html There is another conflict, with the composition modes between the two, with Google again taking another principled stand. I'm sorry I don't supporting links for that, but it effects many of the composite operations (at least four of them). No, it is entirely about antialiasing. Coverage-based antialiasing causes problems whenever you draw two objects with adjacent edges that aren't aligned to pixel boundaries. It doesn't matter whether those boundaries are induced by clipping or just by filling a path. The post you linked to even refers to this: It also refers to Chrome's 1-bit clipping path. I apologize for not having a better reference -- several of the composite results on the following resource have quite different results on Chrome. https://developer.mozilla.org/en/Canvas_tutorial/Compositing Should I perhaps take a different term, and rename this as a masking issue? Would that be more accurate? Chrome has taken a firm stance on how masking should be implemented, Firefox has taken another view. This seems to be something that could be mediated if the standard gives room for both of them, through a simple boolean toggle. If I it were called strictMasking or something like that, would you support it? I want to restrict its effects to the current divide in clip() and globalCompositeOperation because that's where the trouble is. I'm not trying to add a new feature, just trying to bring two implementations to the same standard. -Charles
Re: [whatwg] Canvas Proposal: aliasClipping property
On Fri, Oct 9, 2009 at 11:25 AM, Charles Pritchard ch...@jumis.com wrote: I apologize for not having a better reference -- several of the composite results on the following resource have quite different results on Chrome. https://developer.mozilla.org/en/Canvas_tutorial/Compositing That is probably a completely separate issue, although without more details I can't be sure. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
[whatwg] Canvas Proposal: aliasClipping property
There have been a few discussions about anti-aliasing / aliasing in
Canvas implementations.
Of those I read through, the conflict remains.
In some implementations: when drawImage is used along with a clipping path,
feathering is applied. This shows up in several projective
transformation demos
contrasting Firefox with Chrome.
I believe that if we allow a toggle for this setting, we can bring some
compatibility
to the two systems.
Enumerate two aliasClipping values : aliased, feathered
I consider anti-aliased to confusing, I think feathered is a better
name.
.
[Supplemental]
interface CanvasRenderingContext2D {
attribute DOMString aliasClipping; // default feathered
}
context . aliasClipping [ = value ]
Returns the current aliasing of the clipping region, as applied to
rendering operations.
Can be set, to change the aliasing value.
If any of the arguments are not implemented, throws a
NOT_SUPPORTED_ERR exception.
CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw
NOT_SUPPORTED_ERR; }
Re: [whatwg] Canvas Proposal: aliasClipping property
This sounds like a very good proposal, but can we extend it to include other
things than just drawImage? I'm not sure how useful it would be, but it
could perhaps include all the other drawing options, like stroking and
filling paths created with lineTo, arc, etc.
Marius Gundersen
On Sun, Oct 4, 2009 at 9:10 AM, Charles Pritchard ch...@jumis.com wrote:
There have been a few discussions about anti-aliasing / aliasing in Canvas
implementations.
Of those I read through, the conflict remains.
In some implementations: when drawImage is used along with a clipping path,
feathering is applied. This shows up in several projective transformation
demos
contrasting Firefox with Chrome.
I believe that if we allow a toggle for this setting, we can bring some
compatibility
to the two systems.
Enumerate two aliasClipping values : aliased, feathered
I consider anti-aliased to confusing, I think feathered is a better
name.
.
[Supplemental]
interface CanvasRenderingContext2D {
attribute DOMString aliasClipping; // default feathered
}
context . aliasClipping [ = value ]
Returns the current aliasing of the clipping region, as applied to
rendering operations.
Can be set, to change the aliasing value.
If any of the arguments are not implemented, throws a NOT_SUPPORTED_ERR
exception.
CanvasRenderingContext2D.prototype.defineSetter('aliasClipping') { throw
NOT_SUPPORTED_ERR; }
Re: [whatwg] Canvas Proposal: aliasClipping property
I think feathered isn't a good term. It's vary rarely used in graphics in my experience. aliasClipping isn't a good term either, since there's no clipping going on typically. I would just have boolean property named antialias. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
