Allow pre-parsed data (to scale id's)

[kurkle]

The

set _parsed in the Element directly to reference that original user provided object

From #6766 (comment)

Could be this simple.

Data needs to be array of {x-scale-id: value, y-scale-id: value}

Todo:

• docs
• partial updates (account for start / count)

[benmccann]

We'll probably want to update the default scale IDs

I also wonder if this would allow us to remove Scale._parse or at least TimeScale._parse. We could simply have the user change the scale ID from x to t instead of parsing both attributes

[kurkle]

I'd actually remove support for t. and Scale._parseObject.
Scale._parse is still needed for un-parsed data.

Could also have the input option, input: {x: 't'}// scale-id: input_property

[benmccann]

cool! I'm eager to see how this helps the uPlot benchmark :-)

[kurkle]

Master: (averages around 270ms)

master + this (and parsed: true): (averages around 240ms)

So the difference is around 30 ms, which is almost 10% now!
I like the fact that prepData, that prepares the benchmark is getting to the top .

Edit:
For reference, on this same machine:
2.9.3 ~650ms.
2.8.0 ~1200ms

[benmccann]

I think float bar probably won't work because the _custom field won't get populated

[kurkle]

I think float bar probably won't work because the _custom field won't get populated

If the user provides the _custom as expected for float bars, then it would work.
Maybe there should be a bit more info. Like "Any custom parsing done by the controller needs to be replicated in this mode?"

[benmccann]

I think we probably need some docs about scale parsing. E.g. the time scale will require the user to pass milliseconds since the epoch if this option is enabled

We can ignore _custom in this PR and address it later. I think making the user specify _custom is a bit of an ugly API and we can probably come up with something nicer from the user perspective

[benmccann]

just the two minor docs comments, but looks good to me