Changed reorder()'s sort to be stable

[KPWhiver]

The Array.sort() function in reorder() can be unstable depending on the browser. This means that if some of the values passed in to the reorder() function result in having the same pixel height, their respective dimensions might be ordered differently everytime reorder() is called. To solve this issue, the dimensions are ordered on name whenever such a conflict occurs.

[KPWhiver]

Two more commits were added to my fork. They concern a new feature that allows you to render the brushed items with a different color, instead of removing the non brushed items.

[syntagmatic]

I think https://github.com/KPWhiver/parallel-coordinates/commit/ee6398576a6628532b6fca951dc49cf8b5e53078 should be merged at any time.

https://github.com/KPWhiver/parallel-coordinates/commit/09b3fb51c3d22fc01b26b6e382c8a37480706a7c also looks good, enabling smarter brushes and exposing the hidden function brushExtents

https://github.com/KPWhiver/parallel-coordinates/commit/6bc150dce2f2d4cae69529757b1e558224dfbae8 brings up, for me, some uncomfortable issues about the rendering API. It's quite configuration-oriented and relies on numerous boolean tests in the core code. d3.parcoords strongly assumes a 2d <canvas> context. Actually an SVG context would be more useful for expert d3 users (or print publications) while Julian's WebGL context would be more useful as a high-performance context.

I'm on the fence about tagBrushed in the third commit. This modifies an attribute on the dataset. Does it enable the brushes to do less bookkeeping? Or is it extra bookkeeping?

Thanks Klaas for the contribution! I'll leave it to @bbroeksema to decide what to merge

[KPWhiver]

I have changed the way the brushed items are rendered. There is now a new canvas layer called brushed which is between foreground and highlight. On this canvas layer the brushed items are rendered. The brushed attribute is no longer needed, so the data is not modified.

[KPWhiver]

@syntagmatic: Based on some feedback from @bbroeksema I have changed the last commit a bit. Instead of a brushedRenderMode there are now two functions with which the same (and more) can be achieved: -brushedColor behaves like color, but only for the items on the brushed canvas layer (it defaults to using color) -alphaOnBrushed fades the foreground layer when brushing takes place (it defaults to 0)

In principle these functions make the current shadows canvas layer obsolete, and it could be removed. The current functionality is more flexible and also faster since it uses renderqueue to render the brusheddata.

[bbroeksema]

@syntagmatic I merged all changes from Klaas and did some additional work to update the the shadows functionality, update the documentation and do a version bump.

For your reference:

• c0408b8ece1300efadc4ef6ba37f57b3c60a76a1
• 9aa27305fc66223b7536779c65ea23249d11ee13
• 1f6c91f186ea22b561eb73531c64adbeb6bc8190

If you still have objections against c4f67186efa9b1b4836cd3e6e0bc8c4f329ffd7d, please let me know and I'll make an effort to address the issues. However, I think @KPWhiver did a good job and we have good results in our application with this new functionality. For now closing the pull request.

[syntagmatic]

No objections! Great work @KPWhiver and thanks @bbroeksema for the merge and version bump. I quite like how http://syntagmatic.github.io/parallel-coordinates/examples/brushing.html looks with the colored shadows.