W3C home > Mailing lists > Public > public-html@w3.org > April 2007

Re: Precision of <canvas> rendering (was: Re: Formal definition of HTML5)

From: David Hyatt <hyatt@apple.com>
Date: Tue, 17 Apr 2007 14:00:37 -0700
Message-Id: <CA2E506A-E923-496B-81E7-C20A8D0BAAD3@apple.com>
Cc: "Joe D'Andrea" <jdandrea@gmail.com>, public-html@w3.org
To: Henri Sivonen <hsivonen@iki.fi>

Agreed.  And in practice we've already seen that interoperability is  
achievable without having down-to-the-pixel identical renderings in  
each browser.


On Apr 17, 2007, at 1:57 PM, Henri Sivonen wrote:

> On Apr 16, 2007, at 22:15, Joe D'Andrea wrote:
>> My takeaway thus far:
>> <canvas> should not define pixel-perfect rendering, nor does it.
> <canvas> is really about providing a JavaScript API for the PDF 1.4  
> imaging model in a way that maps sanely to the kind of C libraries— 
> Quartz 2D in particular—that would be suitable for implementing the  
> painting part of a PDF 1.4 viewer. I'd expect the spec to give room  
> for using such libraries without making onerous requirements about  
> the details of Bézier tesselation or the details of anti-aliasing.  
> For example, it should be permissible to use Quartz 2D, Cairo or  
> WPF as the rendering library with whatever anti-aliasing algorithms  
> that they provide.
> Thus, for a given CSS pixels to device pixels ratio,  
> implementations should (subject minor to Bézier tesselation  
> rounding errors) have an agreement about which shapes participate  
> in which pixels, but when a pixel is not fully filled by a given  
> shape, the exact degree of anti-aliasing shading should be allowed  
> to fudge in an implementation-specific way.
> -- 
> Henri Sivonen
> hsivonen@iki.fi
> http://hsivonen.iki.fi/
Received on Tuesday, 17 April 2007 21:00:53 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:15:19 UTC