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
