Timeline incorrectly redraws non-visible items many times if a custom order function is provided

[YoshiWalsh]

In the Vis Timeline documentation it warns about performance when using a custom sort function on large data sets:

WARNING: Use with caution. Custom ordering is not suitable for large amounts of items. On load, the Timeline will render all items once to determine their width and height. Keep the number of items in this configuration limited to a maximum of a few hundred items.

However it turns out that the performance impact of a custom order function is actually much more severe. Through experimentation, I have discovered that if a custom order function is specified, every non-visible item is rendered once every frame. This is absolutely hammering the performance of my application so I'm really hoping to find a fix for it.

Here's a screenshot of the Chrome Performance tab for my application as I click and drag to pan the timeline. The two executions of the forEach function within Group.prototype.redraw account for almost 1.6 seconds together, on a timeline containing 511 items. With more items the performance becomes even worse.

Here's an example that demonstrates the issue. In this example I have hooked the ItemSet and RangeItem redraw functions to monitor how many individual items are redrawn each time that an itemset is redrawn. (I also track which of these redrawn items have new DOM elements created, or have their elements newly attached to the DOM)

The example I posted generates 1000 items. As I drag my view around I can see 985 items being redrawn every frame. I count the currently visible items and there are 15, meaning every non-visible item is being drawn repeatedly. Additionally, all these items are being attached to the DOM, which I believe triggers a DOM reflow. For simple items like in my example this isn't too big a problem, but when the item template contains a bit of complexity then this has an extremely significant performance impact. In my application when I click & drag the timeline I see frame times of over 2,000ms.

I believe the behaviour should be updated to match the documentation.