Hacker Newsnew | comments | show | ask | jobs | submit | ygra's comments login

Most of is is handwritten. D3 for example is only used for the colour picker.

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).

Those are usually called "graphs" ;-) They are listed under "network" (of course there are lots of types or styles here, too).

This is for Chakra, IE's JS JIT. Of course the browser's C++ code is likely compiled with SIMD support, but that doesn't help the codegen in the JIT compiler for JS.

SVG performance in IE (since IE9) has really been and is stellar, indeed. Chrome caught up mostly by now and at least at work the difference between Chrome and IE for certain tasks is that Chrome spends more time rendering and IE spends more time JavaScripting. Firefox SVG performance has been disappointing, mostly and mobile browsers are often better off with canvas as well since performance is generally constrained there.

SVG performance in IE doesn't date back to VML, though. They just made hardware-accelerated rendering a major feature of their browser back then, while no one else was doing it properly. Similar to how Chrome started with JITting JavaScript to make it fast and everyone else caught up on that afterwards.


    Canvas
      * 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

    SVG
      * 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.

Huh, those I knew came in cardboard sleeves. Which are not as handy as the cases.

IMHO Python gets strings very right. The internal representation is variable, depending on the string's content (to save memory), and the external API only gives you access to code points.

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.


That's only Python 3.3 and above; before that it was an under-defined mess, in CPython depending on compile-time options and often broken with the same UCS-2/UTF-16 mess as numerous other languages.
More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: