If you want to draw a lot of data, you have to use canvas. If you want to have vector graphics, you have to use SVG. What are you supposed to do when you need both? Good luck to you my friend
We solved this problem for our domain by using SVG but bypassing the SVG DOM. Instead of making API calls to build up vector elements, we string together a gigantic blob of SVG markup as text and then splat it into the DOM in one go using innerHTML. This works surprisingly well—it's amazing how much computation you can cram in there without noticing any lag. We rebuild pretty much the entire UI on every mouse move and scroll.
At the time we came up with this trick, there was one big drawback: you couldn't put SVG elements inside HTML elements unless your doctype was XHTML. I believe that has changed with HTML5, but haven't ported that code yet. Can anyone add info here?
I have no idea how close this comes to Web/OpenGL; probably not very close, but it was a way out of the dilemma for us.
Edit: It used to puzzle me why this was so fast, but it seems obvious now. JS engines have optimized string concatentation, and the rendering of all that markup is happening on the C++ side, so both things that have to happen here are relatively quick. What's slow is the trip across the Grand Canyon from JS to the rendering engine, and this technique only does that once. Essentially, you're batching up all your API calls, and that saves you so much that the fact that you're using a horrifically inefficient text protocol to do it doesn't matter.
Here is an introduction. They are not SVG specific but you can build SVG elements in a document fragment, which is a lot faster than appending to the DOM, then append the fragment to the DOM all in one go.
We wanted the SVG to be responsive, but altering the size of the svg itself didn't work well in all browsers. So we put it in a div and resized that and told the svg to fill the div. We have had to set the height on the div otherwise it defaults to the native height of the svg in some browsers, rather than the resized height. The svg did maintain it's proportions however.
Two.js has a WebGL renderer and abstractions for basic vector graphics and polygons. I haven't had the chance to use it in a project yet but it seems promising. Two.js could even be used as a basis for a WebGL charting library (thus providing another layer of abstraction).
I don't understand why the author didn't just do his canvas drawing in a resolution independent (or quasi-independent) way. Just choose a unit relative to the size of the canvas, and do everything in those units, transforming your coordinates to fit the width of the canvas element, which is resized to fit the device.
Essentially, you write your drawing code once and it can render to Canvas, SVG, or VML depending on what you need. It doesn't yet have great documentation or a ton of examples, but it's in use at Facebook in their ads management and the page insights interface.
One thing to note with respect to SVG and Canvas is that these APIs are not nearly as optimized in browsers as HTML is.
Since the web is predominantly HTML, Chrome and other browser devs have focused all their efforts on optimizing it (and JS).
SVG and Canvas rendering has not gotten that kind of attention. However it sounds like they are working on it now.
The upshot is that even if it doesn't seem like it would work today doesn't mean it's dead in the water and we need yet another drawing API. Give it time.
It also means -- and I know this sounds crazy -- that you could try drawing your dots with absolutely positioned 1px by 1px DIVs. I know this sounds absurd but I once worked on a scrolling + scaling timeline widget that performed 10x better when implemented with absolutely positioned HTML DIVs than in SVG.
(And like gruesom noted, it is probably best to blast all your DIVs the DOM in one shot.)
I can second this. Did a mind map + force directed graph where the lines connected at the edges of each node and each node had to be markup/css (so canvas was out). Making the dots slide around the node perimeter smoothly ended up working best by doing some trig and placing them absolutely within the node div. Super hacky but it was what worked.
I've done this too (on http://ssz.fr/ker/ for example) and I've noticed if indeed, HTML DOM was slightly faster than SVG up to a couple Firefox versions ago, I have found it to be consistently slower on Chromium, and about the same in the latest Firefox versions.
And 40k elements is a no way with any method other than canvas on Firefox, though it can sometimes stay somewhat usable with SVG on Chromium.
I am a bioinformatician interested in visualizations too. I totally understand your situation wanting to use D3 but can't because of the amount of bio data.
I've been trying to develop a toy genome browser as a pet project while procrastinating on writing my thesis. I faced a similar problem when rendering a genome feature density plot and found mouse interactions with it was painfully slow. I solved it by rendering the svg with d3 and then use canvg.js to convert the svg into canvas. You can see the toy example here: http://www.nextgenetics.net/tools/browser/browser.html
This prototype shows all genes from human chromosome 1. You can use WASD to scroll and Q/E to zoom in and out. The white density plot on the bottom is d3 made and converted into canvas with canvg. All svg are rendered with d3 using an element pooling system.
I really liked the object model of paper.js, but the very same layers/object model led to some performance issues ol large data sets. So im stuck with custom canvas implementation with no vector/high res export solution.
Nothing it is just vaporware. they put a demo out with some music there promising the next generation html5 framework , but it was only to get funding. This is pure Scamware.
What is funny is the author of Three.js did exactly the same demo ( without the cheesy music ) with his framework, the difference is he has an real framework used by thousand of developpers and he did not need 2 million dollar funding to create it.