Hi David, Great to see this post about D3.js _ I am a fan of D3.js :-)
I have been using D3 based JS lib called plotly https://plot.ly/javascript/ to visualise JSON data from 4D/MongoDB/CSVs/JSON in few projects now. Here are a few prototypes I produced in node.js: http://plotly.tenthmatrix.co.uk/ the great things about this tool is it is super quick to just start building charts. Very less coding required. http://plotly.tenthmatrix.co.uk/test7 is dynamically fetching changed data from server. I have recently added plotly.js in my upcoming CRM app release - I have also used these charts in 4D desktop and our JS Team India has build chart reporting system for Cloud SAAS business apps with great results. I will be releasing some examples working with code on GitHub soon. Stay tuned :-) Cheers / Balinder On 14 January 2017 at 22:29, David Adams <[email protected]> wrote: > 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] > ********************************************************************** > ********************************************************************** 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] **********************************************************************
