[whatwg] Canvas patterns, and miscellaneous other things

Dnia 31-01-2008, Cz o godzinie 02:02 +0000, Ian Hickson pisze:
> On Sat, 23 Jun 2007, Philip Taylor wrote:
> > Similarly, what should toDataURL do when the canvas is really large and 
> > the browser doesn't want to give you a data URI? (Opera returns 
> > 'undefined' if it's >= 30001 pixels in any dimension, and crashes if 
> > it's 30000 in each dimension. Firefox (2 and trunk) crashes or hangs on 
> > Linux if it's >= 32768 pixels in any dimension, and crashes on Windows 
> > if it's >= 65536 pixels).
> 
> User agents may impose implementation-specific limits on otherwise 
> unconstrained inputs, e.g. to prevent denial of service attacks, to guard 
> against running out of memory, or to work around platform-specific 
> limitations. (See ...#hardwareLimitations.)

Although the right way of returning in this case 
is throwing an exception, as noted below.

> 
> 
> > More generally, the spec says "If the user agent does not support the 
> > requested type, it must return the image using the PNG format" - what if 
> > it does support the requested type, but still doesn't want to give you a 
> > data URI, e.g. because it's the wrong size (too large, too small, not a 
> > multiple of 4, etc) or because of other environmental factors (e.g. it 
> > wants you to do getContext('vendor-2d').enableVectorCapture() before 
> > toDataURL('image/svg+xml'))? (Presumably it would be some combination of 
> > falling back to PNG (if you asked for something else), returning 
> > undefined, and throwing exceptions.)
> 
> The spec doesn't define "support the requested type". I could definitely 
> see arguing that support of the requested type is dependent upon other 
> factors, so that returning a PNG is ok. Throwing exceptions in the face of 
> hardware limitations (data too big) is always allowed, as noted above. 
> Also, browsers could crop or extend or stretch the image if the image 
> format requires a particular multiple in its output dimensions. That's 
> just part of outputting the image.
>

Received on Thursday, 31 January 2008 07:54:43 UTC