4 ms·

i figured this was far enough along in the dev cycle now to get some feedback. most charting libs try hard to do as much as possible; uPlot tries hard to do as

i figured this was far enough along in the dev cycle now to get some feedback. most charting libs try hard to do as much as possible; uPlot tries hard to do as little as necessary. if anything, it demonstrates how fast raw Canvas can be in the absence of extra baggage, like mem allocation and inefficient algorithms. i'm still fleshing out the programmatic API and also considering adding bar chart/category functionality, since it captures the other type of useful chart which cannot be represented as a trendline. eg: https://doc-0c-2g-docs.googleusercontent.com/docs/securesc/ha0ro937gcuc7l7deffksulhg5h7mbp1/7mvbi2r6mu40k6gst3q1e4t2kvg5bne8/1570629600000/06662872918353485003/*/1oqsebLsZH8pj4exAVbDthaRhERXqg8mN https://doc-0c-2g-docs.googleusercontent.com/docs/securesc/h...

thomas536 7y ago
Link returns a 403 for me (fyi)
- leeoniya 7y ago
  ah sry, see the bar charts here https://morepypy.blogspot.com/2019/10/pypys-new-json-parser.html?m=1 https://morepypy.blogspot.com/2019/10/pypys-new-json-parser....
onion2k 7y ago
if anything, it demonstrates how fast raw Canvas can be in the absence of extra baggage, like mem allocation and inefficient algorithms Obviously using an efficient algorithm is important, but your point about memory allocation is more interesting. The closest you can get to malloc in a browser is a fixed length typed array, and if you're working with a canvas that's probably Uint8ClampedArray(xSize * ySize * 4) for 24bit color. They're really fast. Why wouldn't you use that? It's definitely not "baggage".
- leeoniya 7y ago
  i considered using typed arrays for the input data, but most data is gonna come from JSON parsing, which will automatically allocate at least the size of a non-typed array, so i used that as the lowest common denominator for the demos. my point was more that many charting libs use record-based datasets like [[a,b],[c,d]] which would need to allocate possibly hundreds of thousands of arrays or objects. uPlot uses something closer to a column store for its data format, which saves a lot of mem, in addition to not duplicating the same timestamps for every series.
NetOpWibby 7y ago
Will you add SVG support?
- leeoniya 7y ago
  the reason this lib is both small and fast is because it does not use svg. if you need svg, there are plenty of great charting libs that have svg backends. don't get me wrong, i love svg, but the performance is much worse.
  - NetOpWibby 7y ago
    I shall await the minimal charting library that uses SVG!
    - amenod 7y ago
      I made it - and quickly rewrote it to use canvas. With many points the performance of SVG is simply not acceptable. On the other hand, for canvas they are just pixels (once they are drawn) - no difference in performance if they are white or green. Note that I love SVG and still use it for the axes and the layers above the chart, but it has too much overhead to be used for drawing the chart values.

thomas536 7y ago

Link returns a 403 for me (fyi)

leeoniya 7y ago
ah sry, see the bar charts here https://morepypy.blogspot.com/2019/10/pypys-new-json-parser.html?m=1 https://morepypy.blogspot.com/2019/10/pypys-new-json-parser....

onion2k 7y ago

if anything, it demonstrates how fast raw Canvas can be in the absence of extra baggage, like mem allocation and inefficient algorithms Obviously using an efficient algorithm is important, but your point about memory allocation is more interesting. The closest you can get to malloc in a browser is a fixed length typed array, and if you're working with a canvas that's probably Uint8ClampedArray(xSize * ySize * 4) for 24bit color. They're really fast. Why wouldn't you use that? It's definitely not "baggage".

leeoniya 7y ago
i considered using typed arrays for the input data, but most data is gonna come from JSON parsing, which will automatically allocate at least the size of a non-typed array, so i used that as the lowest common denominator for the demos. my point was more that many charting libs use record-based datasets like [[a,b],[c,d]] which would need to allocate possibly hundreds of thousands of arrays or objects. uPlot uses something closer to a column store for its data format, which saves a lot of mem, in addition to not duplicating the same timestamps for every series.

NetOpWibby 7y ago

Will you add SVG support?

leeoniya 7y ago
the reason this lib is both small and fast is because it does not use svg. if you need svg, there are plenty of great charting libs that have svg backends. don't get me wrong, i love svg, but the performance is much worse.
- NetOpWibby 7y ago
  I shall await the minimal charting library that uses SVG!
  - amenod 7y ago
    I made it - and quickly rewrote it to use canvas. With many points the performance of SVG is simply not acceptable. On the other hand, for canvas they are just pixels (once they are drawn) - no difference in performance if they are white or green. Note that I love SVG and still use it for the axes and the layers above the chart, but it has too much overhead to be used for drawing the chart values.