You don't necessarily need a million DOM elements. Data points could mean points of a single plot, in which case you have a single path element with lots of points. Generally you can almost always bunch things together in a single path to reduce the number of DOM elements (with other tradeoffs, of course).
* Bitmapped graphics
* Immediate mode
+ Fast for simple things
+ Minimal drawing overhead
- Interactivity has to be handled manually (e.g. by checking whether click coordinates coincide with a drawn button)
- Animating things (usually) mean redrawing most of the canvas for every frame
+ Ability to manipulate pixels if needed
* Everything is drawn manually
* Vector graphics
* Retained mode
+ Fast for simple things
- Everything that needs to be drawn has to exist in the DOM
+ Interactivity can be handled via events by the browser on every element if needed
+ Animating things (usually) just mean to manipulate that thing in the DOM
- Limited ways of arbitrarily manipulating the composed result
* Everything is drawn by the browser
+ CSS support
+ Sophisticated text rendering support
It's mostly a trade-off of what you want to do. The things marked with * above are not clear benefits or drawbacks.
For a chart that consists of axes, ticks, a plot and maybe a few other things I'd always go for SVG unless compatibility constraints force me to go to bitmap graphics. It just maps much better to vectors than to pixels, but there are limits, of course. Heatmaps often are better drawn via canvas, especially those where there are no discrete shapes but rather blurry blobs of colour.
Performance is a difficult topic and hard to compare, beyond simple things: In canvas (mostly) your only option of optimisation is to draw less, i.e. touch fewer pixels; with SVG being rendered and composited by the browser it often boils down to »don't move elements that don't have to move« to enable the browser to render less and not throw away every partially composited texture. In IE and Chrome SVG has quite great performance, in Firefox you have to be careful what you do. Uusally it scales well to a few hundred or thousand DOM elements, though, depending on what you do.
As someone who works in that field, to me "graph drawing" relates even more to drawing and arranging mathematical graphs of nodes and edges (called networks on that site); the conference on that is called Graph Drawing, too. It's also a frequent confusion of potential customers who ask us whether our library handles line and bar "graphs" ...
Both are probably too entangled with Windows internals. Windows Forms is essentially a wrapper around native GDI controls. WPF's rendering system is quite intertwined with the DWM
It's much easier to open-source the things with fewer dependencies, such as .NET Core, ASP.NET and other networking stuff. It's also invariably what customers are likely to want to run on Azure (or elsewhere), just maybe not with Windows underneath it.
For WPF I'm content with MS actually continuing development. WPF is the best UI framework I've used so far with a lot of good ideas that have sadly been ignored by most others. It's just sad that it got so little attention in recent years.
I use WPF everyday and it has many great features. But sadly it was conceptualized before many of the 'modern' and best features of .net. The striking lack of type support (generics), and frankly broken separation between form and function, makes it feel very clunky at times. Not to mention that while data-binding is first class, the predominant MVVM pattern is sadly bolted on. My last gripe is that in most WPF applications, the only reason the application hangs is due to rendering performance - which is truly unacceptable given every other part of my application can be multi-threaded or async.
Entirely true. Still, seems like if they were to open-source WPF, the Mono community would have an interest in trying to abstract out the DirectX dependencies and making it run on OpenGL. Shame we'll probably never see it happen - it would be great to see a true cross-platform GUI toolkit for .NET that's not GTK.
The problem with Python strings is that innocuous operations can occasionally cause drastic memory usage ballooning.
A simple string append can, for instance, require up to 5x the memory consumed by the string.
Worse, this problem will only show up if someone ever enters in a high enough code point. Better hope any user-defined data never gets turned into part of a large string at any point, or you have a potential memory problem down the line.