5 ms·

I tried to use SVG on a recent project and did not have a good experience. The project was converting PDF building plans to SVG and then I had to do some transf

I tried to use SVG on a recent project and did not have a good experience. The project was converting PDF building plans to SVG and then I had to do some transformation UI to align them to a map. It worked, but the performance was terrible for non-trivial documents. Anything over 10 MB started to get unstable and provide for a bad UX in the browser. There's no way to get any kind of incremental rendering, you have very little control over the rendering process in the browser once you've handed it off to SVG (terrible API), and there are all kinds of security restrictions that make lots of hacks necessary if you're loading SVG from some place like S3 (due to same origin policy, but there are some additional hoops to jump through unique to SVG as well). Especially bad was the inconsistency across browsers and different implementations. When something goes wrong in the SVG engine internals, you get cryptic error messages (no stack traces or indication of where to even begin -- most of the time the location of the error referenced in the SVG document is wrong as well, or just at the root element). Opaque "out of memory" errors, or the browser tab just crashes. It very much felt like dealing with a black box. For non-trivial use cases, it makes it very hard to debug. The goal of using SVG was to standardize to a neutral vector format that we could use anywhere, client or server, and leverage a lot of the tools that can deal with SVG or can convert to/from SVG without having to write our own drawing "engine". In the end it wasn't worth all the hassle and we ended up implementing our own drawing using canvas primitives. Too bad.

aidos 10y ago
I have a similar use case (http://www.countfire.com http://www.countfire.com) and we've found svg to be really good. We often deal with documents with hundreds of thousands of Dom nodes. Admittedly we have limited ourselves to supporting google chrome so that might be the difference. Though we did also have to spend quite a bit of time optimizing the way svg manipulation is handled to make things performant.
- iamleppert 10y ago
  Wondering how you feel about that? Was all the extra effort worth it in the end? Considering you only support a single browser anyway. Imagine a similar effort per browser. There's even a lot of variance between Chrome, latest FF, IE Edge, etc. In my case I wasn't even manipulating the actual SVG nodes, just using transform CSS operations on them (transform and transfrom3d).
  - aidos 10y ago
    The final result is really nice. The user experience is smooth, and that's what matters most. I'm not convinced that using canvas would have saved me that much effort. You just don't know what's going to bite you until you start building with these things. One of the nice things with svg is that I can work with it everywhere. In the browser, on the backend, I can even manually manipulate it in my text editor. Fortunately I've opted to constrain myself to chrome. If I had to support all the browsers that would have been the thing that ate up all the time (irrespective of whether it was canvas or svg). Anyway. Sounds like you've also experienced the complexities enough to understand that once you push things a bit harder than usual you need to do extra work to make things play nice :) At the end of the day, I'm happy with the result. Besides, for all the trouble it's nowhere near as complex as other bits of our system!
danjc 10y ago
We ported our Console off Silverlight to HTML and use SVG to render a workflow designer which dynamically overlays HTML overlays for most editing. Our experience with SVG has been fantastic and we've found it very performant even on large workflows that are 20x screen area. I should note that we are using React too with shouldComponentUpdate implemented to optimize DOM mutation. Example at https://flowgear.me/s/hZfxYnf https://flowgear.me/s/hZfxYnf
- ygra 10y ago
  We have a graph editing and display component, which is primarily built on SVG (canvas rendering available, too). Performance is rarely a problem. Admittedly, we do remove elements that are not visible from the DOM, for very large graphs those have to be tweaked a bit (same goes for WPF). Generally usability suffers before performance does, and most techniques of improving usability also improve performance.

aidos 10y ago

I have a similar use case (http://www.countfire.com http://www.countfire.com) and we've found svg to be really good. We often deal with documents with hundreds of thousands of Dom nodes. Admittedly we have limited ourselves to supporting google chrome so that might be the difference. Though we did also have to spend quite a bit of time optimizing the way svg manipulation is handled to make things performant.

iamleppert 10y ago
Wondering how you feel about that? Was all the extra effort worth it in the end? Considering you only support a single browser anyway. Imagine a similar effort per browser. There's even a lot of variance between Chrome, latest FF, IE Edge, etc. In my case I wasn't even manipulating the actual SVG nodes, just using transform CSS operations on them (transform and transfrom3d).
- aidos 10y ago
  The final result is really nice. The user experience is smooth, and that's what matters most. I'm not convinced that using canvas would have saved me that much effort. You just don't know what's going to bite you until you start building with these things. One of the nice things with svg is that I can work with it everywhere. In the browser, on the backend, I can even manually manipulate it in my text editor. Fortunately I've opted to constrain myself to chrome. If I had to support all the browsers that would have been the thing that ate up all the time (irrespective of whether it was canvas or svg). Anyway. Sounds like you've also experienced the complexities enough to understand that once you push things a bit harder than usual you need to do extra work to make things play nice :) At the end of the day, I'm happy with the result. Besides, for all the trouble it's nowhere near as complex as other bits of our system!

danjc 10y ago

We ported our Console off Silverlight to HTML and use SVG to render a workflow designer which dynamically overlays HTML overlays for most editing. Our experience with SVG has been fantastic and we've found it very performant even on large workflows that are 20x screen area. I should note that we are using React too with shouldComponentUpdate implemented to optimize DOM mutation. Example at https://flowgear.me/s/hZfxYnf https://flowgear.me/s/hZfxYnf

ygra 10y ago
We have a graph editing and display component, which is primarily built on SVG (canvas rendering available, too). Performance is rarely a problem. Admittedly, we do remove elements that are not visible from the DOM, for very large graphs those have to be tweaked a bit (same goes for WPF). Generally usability suffers before performance does, and most techniques of improving usability also improve performance.