5 ms·

Why implement vector graphics on Canvas when you could use SVG? EDIT: Seems to be answered in the FAQ: "We have decided to use the Canvas object as the main ba

Why implement vector graphics on Canvas when you could use SVG? EDIT: Seems to be answered in the FAQ: "We have decided to use the Canvas object as the main backend for now because it is faster than SVG and allows us to implement and optimize our own Scene Graph / Document Object Model. We will be offering SVG (and hopefully PDF) importing and exporting in the future." But it seems hard to believe that doing vector->bitmap rasterization in JavaScript is going to be faster than using the browser's SVG implementation (written in C++).

csytan 15y ago
I don't think SVG is particularly suited to animation, as it would require manipulating multiple DOM elements. This tends to be quite slow compared to redrawing the canvas.
- haberman 15y ago
  The alternative is keeping your own "DOM" of vector objects in a JavaScript-based scene graph. Why would this be more efficient than manipulating the DOM?
  - donpark 15y ago
    Because DOM elements are much heavier than Javascript objects in size, query/update performance, and update requirements.
- MatthewPhillips 15y ago
  SVG is hardware accelerated in IE9 and coming to Chrome as well. When that happens I doubt there will be much of a difference performance wise. Canvas and SVG will serve different ends. Doing something like GUI in Canvas would be an incredible pain, whereas doing it in SVG (using raphael.js) is a breeze. Canvas is better for games.
- euroclydon 15y ago
  Don't forget SMIL.
deleted 15y ago
[deleted]
epistasis 15y ago
There's no reason that a Canvas implementation would be doing rasterization in JavaScript; the Canvas API is like Postscript or the Cairo API, and javascript will only be calling high-level functions such as specifying gradient or Bezier curve parameters.
perfunctory 15y ago
This is what amuses me about software. SVG which is specifically designed for vector graphics is slower than "not native" solution.
- epistasis 15y ago
  The problem with SVG was that it wasn't really designed as much as it was dreamed. And it was also dreamed up in the middle of the whole "all data must be shoe-horned into XML" collective nightmare, which makes it less than ideal as a scene graph. It was also abandoned as soon as Adobe acquired Macromedia, and thus Flash, meaning that there was no longer any reason for Adobe to push for a Flash alternative. There have never really been any good implementations, and it seems as though the spec wasn't written by anybody who'd have to eventually write an implementation.
  - haberman 15y ago
    Any specific criticisms of SVG's design (or references to such), besides being built on top of XML (which is unfortunate, I agree)? Also, what's wrong with the mainstream SVG implementations, like in WebKit and Gecko?
    - epistasis 15y ago
      For many many years the web browser implementations have been buggy and incomplete, and it was always difficult for me to figure out what I could and couldn't use on which browsers and which operating systems. I don't have any specific complaints other than a myriad of tiny tiny headaches that I've left in the past. A lot of them revolved around text APIs and especially the DOM interfaces. I ran into far fewer bugs and inconsistencies when just using static XML. From what I can tell the browser implementations are getting much better. It has been very odd that browsers have been shipping half-broken implementations for years, and the specification was released in 2003, a full eight years ago. I think that the failure to implement SVG can largely be traced back to the extreme breadth and complexity of the specification. It's much easier to read through the specification for OpenGL or Postscript than it was to make it through the SVG specification, though I admit that a procedural API is almost necessarily simpler and easier than a stateful scene graph that includes a procedural API on top of it. Maybe SVG Tiny and Mobile mitigate the problem, but those came far too late to make a difference, and SVG 1.1 certainly wasn't deprecated in favor of a smaller and more implementable set of functionality. In ay case, I'm not going to be guinea pig for SVG again. I may pick it up when others have proven that it has several interoperable implementation on separate OSs, but I still consider it one of the bigger time-sucks and poor architectural decisions I've made. /rant
neimado 15y ago
It still does nothing to support the millions of IE6, 7 & 8 users, and VML has been around since IE5.x - it's really not much different than SVG either. Seeing a vector library these days that doesn't support VML is just sad. I've written my own and it works back to IE5.5. Animation performance isn't great but it isn't that bad either. IE's DOM is actually not as slow as one might think it is.

csytan 15y ago

I don't think SVG is particularly suited to animation, as it would require manipulating multiple DOM elements. This tends to be quite slow compared to redrawing the canvas.

haberman 15y ago
The alternative is keeping your own "DOM" of vector objects in a JavaScript-based scene graph. Why would this be more efficient than manipulating the DOM?
- donpark 15y ago
  Because DOM elements are much heavier than Javascript objects in size, query/update performance, and update requirements.
MatthewPhillips 15y ago
SVG is hardware accelerated in IE9 and coming to Chrome as well. When that happens I doubt there will be much of a difference performance wise. Canvas and SVG will serve different ends. Doing something like GUI in Canvas would be an incredible pain, whereas doing it in SVG (using raphael.js) is a breeze. Canvas is better for games.
euroclydon 15y ago
Don't forget SMIL.

deleted 15y ago

[deleted]

epistasis 15y ago

There's no reason that a Canvas implementation would be doing rasterization in JavaScript; the Canvas API is like Postscript or the Cairo API, and javascript will only be calling high-level functions such as specifying gradient or Bezier curve parameters.

perfunctory 15y ago

This is what amuses me about software. SVG which is specifically designed for vector graphics is slower than "not native" solution.

epistasis 15y ago
The problem with SVG was that it wasn't really designed as much as it was dreamed. And it was also dreamed up in the middle of the whole "all data must be shoe-horned into XML" collective nightmare, which makes it less than ideal as a scene graph. It was also abandoned as soon as Adobe acquired Macromedia, and thus Flash, meaning that there was no longer any reason for Adobe to push for a Flash alternative. There have never really been any good implementations, and it seems as though the spec wasn't written by anybody who'd have to eventually write an implementation.
- haberman 15y ago
  Any specific criticisms of SVG's design (or references to such), besides being built on top of XML (which is unfortunate, I agree)? Also, what's wrong with the mainstream SVG implementations, like in WebKit and Gecko?
  - epistasis 15y ago
    For many many years the web browser implementations have been buggy and incomplete, and it was always difficult for me to figure out what I could and couldn't use on which browsers and which operating systems. I don't have any specific complaints other than a myriad of tiny tiny headaches that I've left in the past. A lot of them revolved around text APIs and especially the DOM interfaces. I ran into far fewer bugs and inconsistencies when just using static XML. From what I can tell the browser implementations are getting much better. It has been very odd that browsers have been shipping half-broken implementations for years, and the specification was released in 2003, a full eight years ago. I think that the failure to implement SVG can largely be traced back to the extreme breadth and complexity of the specification. It's much easier to read through the specification for OpenGL or Postscript than it was to make it through the SVG specification, though I admit that a procedural API is almost necessarily simpler and easier than a stateful scene graph that includes a procedural API on top of it. Maybe SVG Tiny and Mobile mitigate the problem, but those came far too late to make a difference, and SVG 1.1 certainly wasn't deprecated in favor of a smaller and more implementable set of functionality. In ay case, I'm not going to be guinea pig for SVG again. I may pick it up when others have proven that it has several interoperable implementation on separate OSs, but I still consider it one of the bigger time-sucks and poor architectural decisions I've made. /rant

neimado 15y ago

It still does nothing to support the millions of IE6, 7 & 8 users, and VML has been around since IE5.x - it's really not much different than SVG either. Seeing a vector library these days that doesn't support VML is just sad. I've written my own and it works back to IE5.5. Animation performance isn't great but it isn't that bad either. IE's DOM is actually not as slow as one might think it is.