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

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

dave

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