3 ms·

"using maths". that sounds like an entirely different solution than building interfaces, which is what this presentation was about. The example you cited with

"using maths". that sounds like an entirely different solution than building interfaces, which is what this presentation was about. The example you cited with 500K DOM nodes.. Really? How as the browser performance? Why not just convert to canvas at that high level of DOM elements?

aidos 10y ago
It is different but I guess my point was that SVG is a brilliant tool for developers. We (generally) approach problems in a programatic way, and SVG allows you to do that for graphics, which is incredibly liberating. Performance is good! I've definitely had to come up with some pretty clever hacks but it feels smooth once the SVG has loaded. In our case we need to be able to zoom in to arbitrary levels and still have crisp vectors. Here's an example of a document with about 150,000 dom nodes. You'll see that it's a little sluggish when you're zooming in and out but after it catches up it's really quick to move around. Most of our documents are much smaller than this so there's no real delay on zoom in those cases. https://dl.dropboxusercontent.com/u/233998/example_movement.mov https://dl.dropboxusercontent.com/u/233998/example_movement....
- jordache 10y ago
  is it suppose to be device agnostic? I'm on a core i7 device so it's not a good indicator of how performant a given web solution is. Generally speaking when you have that many elements, you've surpassed the threshold of what SVG is intended to do. Canvas can be a seamless replacement for SVG without any tradeoffs, other than additional build complexity
  - aidos 10y ago
    The problem with canvas is that our users need to be able to zoom very deep and still have crisp rendering. We wouldn't get that with canvas unless we rendered to a really huge canvas, right? Yeah, the machine is definitely going to make a difference, though as I say a) most our documents are smaller than this and b) we have ways of speeding up bigger documents where required. Sure, SVG isn't made for this, but it works. Going to canvas would mean a load of extra work and you can be sure there would be other tradeoffs and issues to work around. Additionally, SVG is super hackable. You can work with it easily front and back end. You can read it and understand what's going on. And hey, if your users are happy.... :-) http://www.capterra.com/takeoff-software/spotlight/144811/Countfire/Rapid%20Tender http://www.capterra.com/takeoff-software/spotlight/144811/Co...
    - jordache 10y ago
      i think you can redraw the canvas when zooming in. So even if the canvas dimension is finite, you can redraw it with infinitely higher resolutions of data.
      - aidos 10y ago
        I get the idea, but then I'll be doing the work that the SVG engine is currently doing. So really, here you're trying to get canvas to do something that it wasn't designed to do - which is weird, because that was your argument against svg in the first place. A quick google reveals the general solution of "sounds like you should be using svg." [0] Given that svg 100% works for my usecase, I don't have any reason to attempt anything else at the moment. People give svg a hard time about performance and I think that's counterproductive. My suggestion is that everyone should give it more of an honest shot and I suspect they'll find that there are plenty of cases when it becomes the first tool they reach for. [0] http://stackoverflow.com/questions/19284304/how-redraw-on-canvas-resize-without-blurring http://stackoverflow.com/questions/19284304/how-redraw-on-ca...

aidos 10y ago

It is different but I guess my point was that SVG is a brilliant tool for developers. We (generally) approach problems in a programatic way, and SVG allows you to do that for graphics, which is incredibly liberating. Performance is good! I've definitely had to come up with some pretty clever hacks but it feels smooth once the SVG has loaded. In our case we need to be able to zoom in to arbitrary levels and still have crisp vectors. Here's an example of a document with about 150,000 dom nodes. You'll see that it's a little sluggish when you're zooming in and out but after it catches up it's really quick to move around. Most of our documents are much smaller than this so there's no real delay on zoom in those cases. https://dl.dropboxusercontent.com/u/233998/example_movement.mov https://dl.dropboxusercontent.com/u/233998/example_movement....

jordache 10y ago
is it suppose to be device agnostic? I'm on a core i7 device so it's not a good indicator of how performant a given web solution is. Generally speaking when you have that many elements, you've surpassed the threshold of what SVG is intended to do. Canvas can be a seamless replacement for SVG without any tradeoffs, other than additional build complexity
- aidos 10y ago
  The problem with canvas is that our users need to be able to zoom very deep and still have crisp rendering. We wouldn't get that with canvas unless we rendered to a really huge canvas, right? Yeah, the machine is definitely going to make a difference, though as I say a) most our documents are smaller than this and b) we have ways of speeding up bigger documents where required. Sure, SVG isn't made for this, but it works. Going to canvas would mean a load of extra work and you can be sure there would be other tradeoffs and issues to work around. Additionally, SVG is super hackable. You can work with it easily front and back end. You can read it and understand what's going on. And hey, if your users are happy.... :-) http://www.capterra.com/takeoff-software/spotlight/144811/Countfire/Rapid%20Tender http://www.capterra.com/takeoff-software/spotlight/144811/Co...
  - jordache 10y ago
    i think you can redraw the canvas when zooming in. So even if the canvas dimension is finite, you can redraw it with infinitely higher resolutions of data.
    - aidos 10y ago
      I get the idea, but then I'll be doing the work that the SVG engine is currently doing. So really, here you're trying to get canvas to do something that it wasn't designed to do - which is weird, because that was your argument against svg in the first place. A quick google reveals the general solution of "sounds like you should be using svg." [0] Given that svg 100% works for my usecase, I don't have any reason to attempt anything else at the moment. People give svg a hard time about performance and I think that's counterproductive. My suggestion is that everyone should give it more of an honest shot and I suspect they'll find that there are plenty of cases when it becomes the first tool they reach for. [0] http://stackoverflow.com/questions/19284304/how-redraw-on-canvas-resize-without-blurring http://stackoverflow.com/questions/19284304/how-redraw-on-ca...