Add ticks.sampleSize option

[benmccann]

This allows users to set a sampleSize option which is a major performance improvement when there's a large number of ticks / labels

The charts render nearly twice as fast with this option. Here's timing information for samples/scales/time/financial.html changed to render 8,000 datapoints:
Without this PR: 520ms
With sampleSize: 100: 272ms

Plunker: https://plnkr.co/edit/Bj6unMv5JSL69nfUZ3zx?p=preview

[kurkle]

I like the idea, but I don't like the implementation. Its getting really hard to follow what is contained in ticks or me.ticks or me._ticks at different stages and why.

Could the same performance gain be achieved by just changing computeLabelSizes to use sampleSize?

[benmccann]

Could the same performance gain be achieved by just changing computeLabelSizes to use sampleSize?

Unfortunately, it's a little more complicated than that. The main thing we want to do to achieve the performance gains is have convertTicksToLabels happen after auto-skipping. Unfortunately, it's almost impossible to re-order the methods because there are so many inter-dependencies between. them. E.g. _autoSkip relies on fit and calculateTickRotation having already been called. calculateTickRotation and _autoSkip both rely on _getLabelSizes which relies on _ticks having been defined, etc. Rather than reordering too much, I found it much simpler to call _convertTicksToLabels twice.

I like the idea, but I don't like the implementation. Its getting really hard to follow what is contained in ticks or me.ticks or me._ticks at different stages and why.

I agree that it's quite hard to follow ticks vs me.ticks vs me._ticks. Though I think that problem exists quite a bit in master as well and am not sure this PR makes it much worse. I reverted a change I made to afterBuildTicks. Perhaps it's clearer now? I really can't wait to be able to get rid of me.ticks in v3 because it makes this code extremely difficult to work with.