4 ms·

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
    - haberman 15y ago
      Thanks for writing that up. I've gotten more interested in SVG ever since Protovis's successor d3 adopted an approach of writing SVG directly. d3's has some impressive demos built on top of SVG in an impressively small amount of code: http://mbostock.github.com/d3/ http://mbostock.github.com/d3/ I do think it's unfortunate that lots of W3C standards like SVG were well-positioned to be very widely used, but ended up being so big, complicated, and not informed by actual implementations. I've ranted about this before: http://news.ycombinator.com/item?id=2521885 http://news.ycombinator.com/item?id=2521885
    - david927 15y ago
      You say it much more eloquently than I could but I wholeheartedly agree. I'm done getting bitten by SVG when Canvas, while more work, never bites.

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
  - haberman 15y ago
    Thanks for writing that up. I've gotten more interested in SVG ever since Protovis's successor d3 adopted an approach of writing SVG directly. d3's has some impressive demos built on top of SVG in an impressively small amount of code: http://mbostock.github.com/d3/ http://mbostock.github.com/d3/ I do think it's unfortunate that lots of W3C standards like SVG were well-positioned to be very widely used, but ended up being so big, complicated, and not informed by actual implementations. I've ranted about this before: http://news.ycombinator.com/item?id=2521885 http://news.ycombinator.com/item?id=2521885
  - david927 15y ago
    You say it much more eloquently than I could but I wholeheartedly agree. I'm done getting bitten by SVG when Canvas, while more work, never bites.