Bertrand, Since you brought it up....
That was a pretty interesting piece, but they very unfortunately went to a great deal of work and missed out on a lot of existing information. Here's a better post on the same subject: http://www.visualcinnamon.com/2015/11/learnings-from-a-d3-js-addict-on-starting-with-canvas.html For those of you following along at home, a recap: * If what you want are Web-based business charts, pay for HighCharts and move on. It just looks fantastic and very easy to use. D3 is...something else. If you need to invent a new chart type, go with D3. * D3 binds data to DOM elements in a browser. It's SVG. That's the default. * Browsers render SVG using the CPU (mostly, if not entirely.) That tops out. People with substantial data sets where they need to render thousands of moving objects simultaneously hit a performance wall. * The big problem is the big DOM. Fact of life. * But SVG is awesome! Transitions, styling, native objects, vectors. Vectors! So good. But you just hit a wall at some point. Not a D3 specific issue, but an issue that D3 users run into, if they have huge data sets with complex rendering. (My data sets aren't that size, but some people's sets are.) Enter HTML5 and the Canvas object. It is a *bitmap* rendering space, not a vector space. Eh? It's pushed out to the GPU, so you can get *massive* processing power for "free." This is exactly why I said the other day (roughly): "Cores? Who cares about cores. The cool kids are pushing stuff to the GPU." You can render ginormous data sets to a bitmap this way and it works great. These days, it's not that common to optimize something by pushing it to a different bit of hardware, but that's the case here. But wait..bitmap...so how do you get events? Transitions? You don't. They're bitmaps - static. So you have to put more work into simulating those features. To get transitions (frame animation), you have to renderer the scene over, and over, and over very quickly. So you end up doing vastly more work, but the result executes more quickly because of all of the GPU processing. That's the point behind taking advantage of WebGL. (The post Bernard listed doesn't seem to explain this - but that's the reason to push things to WebGL, it's GPU optimized for the bitmaps.) Okay, we've got animation back. What about events? I mean when you click on a "circle" or something, there's no circle object there - it's just a pixel like all of the others. I've seen two approaches. One is that you overlay a Voronoi diagram: https://en.wikipedia.org/wiki/Voronoi_diagram Yeah, like I know what any of that means ;-) There are tons of D3 examples of overlaying Voronoi diagrams for various reasons. The other technique (and the one I'll guess that the Pixi library mentioned uses) is to take advantage of a spare bit of information in the pixel You can generate a unique 'color index' in a non-display area so that each pixel has its own unique ID. Kind of cool and very efficient. Then you need to have a mapping system to translate which "object" that pixel is a part of. Click-get color index-lookup index in map-figure out if the click is in an 'object'-run appropriate event handling code. I haven't implemented either of these techniques. I managed to make it up to the first day of 4D's very nice world tour last year and JPR showed a renderer in 4D that had pixel-level responsiveness for millions of pixels. I assumed he was using a technique similar-if-not-identical-to the second one. (In which case, moving it to a WebArea + JS + Canvas would get you GPU acceleration.) I couldn't come to the second day, so I never did find out if that's how he was doing it! This is all off the top of my head, first thing in the morning...and, again, I haven't implemented either of these things. Why, in fact, do I even know about all of this? Well, when I learn a new tool, I like to poke around at the edges a lot and see what sort of problems people run into. That way, if you ever do run into it, you know how other people have already solved the problem. The idea of an overcrowded DOM is pretty obvious and easy to run into at scale, so it pops up frequently. I'm surprised that the folks in the blob post that Bertrand mentioned had to "reinvent the car" on this one. Oh, I should also add that Mike Bostock (Mr. D3) is well aware of this issue and has been for years. He's had lots of posts, proof-of-concept code for working with Canvas and such. In fact, version 4 of D3 (out for several months), adds support for abstracting the rendering engine. Meaning, you can render to SVG or Canvas. At least for some of the primitives. So, targeting Canvas - for the very reasons mentioned in the post Bertrand listed - is a core feature of the shipping version of D3 and support will only increase over time. He's got a bunch of blog posts about it but I don't have them to hand. Unfortunately, I haven't been able to work on D3 for about 6 months or since the V4 release. I've got a roadmap that takes me back to D3, but there's a few months of prep work before I get there. Looking forward to. The thing is just amazing. It's a turning point in data visualization, no joke. Super big deal. ********************************************************************** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: http://lists.4d.com/archives.html Options: http://lists.4d.com/mailman/options/4d_tech Unsub: mailto:[email protected] **********************************************************************
