[whatwg] SVG extensions to <canvas>

[Ian Hickson]

On Fri, 1 May 2009, Simon Pieters wrote:
> On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson <ian at hixie.ch> wrote:
> > On Thu, 25 Oct 2007, Anne van Kesteren wrote:
> > > 
> > > For Opera 9.5 beta we implemented some experimental extensions to 
> > > <canvas> involving SVGSvgElement. SVGSvgElement is supported as 
> > > "image" argument to both drawImage and createPattern. (An 
> > > HTMLImageElement pointing to an SVG element is also supported, but 
> > > that seems natural if you support SVG from <img>.)
> > > 
> > > For drawImage the pixel size of the SVG is determined as follows:
> > > 
> > >   1. The image size parameters passed to drawImage
> > >   2. The intrinsic size of the SVG image
> > >   3. 300 x 150
> > > 
> > > For createPattern it is as follows:
> > > 
> > >   1. The intrinsic size of the SVG image
> > >   2. 300 x 150
> > > 
> > > (It would be nice if createPattern was extended to allow 
> > > height/width arguments as well.)
> > > 
> > > The intrinsic size of the SVG image is the specified size with 
> > > percentages resolved against 300 x 150, and sizes depending on the 
> > > font-size resolved against the computed font-size of the 
> > > SVGSvgElement (will be the browser default most of the time).
> > > 
> > > The SVG image is always rendered at time 0 for animated images.
> > > 
> > > Drawing an SVG image currently marks the canvas context as unsafe so 
> > > toDataURL() and getImageData() throw. We expect to make this story a 
> > > bit nicer at some point.
> > 
> > As far as I can tell this doesn't require any changes to HTML5, since 
> > the same applies here as applies to a regular <img>, right?
> 
> It would at least have to change to make it not throw...
> 
> "The image argument must be an instance of HTMLImageElement, 
> HTMLCanvasElement, or HTMLVideoElement. If the image is of the wrong 
> type or null, the implementation must raise a TYPE_MISMATCH_ERR 
> exception."

Oh, I misunderstood. I thought you meant <svg> in an <img>.

I don't want to add painting of <svg> into <canvas> right now, because on 
the long term I expect we'll have a generic "paint this element into the 
canvas" feature and I would want the two to be the same mechanism.


On Mon, 4 May 2009, Oliver Hunt wrote:
> 
> I'm not sure this is a great idea, as like all other elements the size 
> of an SVGSVGElement may be influenced by where it is in the DOM, which 
> makes it unclear how drawImage(SVGSVGElement) should work, eg. should it 
> use the "natural" size of the element, the size of the element according 
> to its current location in the dom (and what happens if it's not in the 
> dom?), or what?
> 
> I believe drawImage should be left as it currently is (basically taking 
> objects that are intrinsically bitmap-ish), and if we were to add an 
> ability to draw an svg element into the canvas it should really be an 
> simple drawElement(Element) method instead, after all, why restrict it 
> it just to SVG elements?

Indeed.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'