3 ms·

Have you tried running simplifying the lines before rendering? Rendering 150k points is cool, but there aren't enough pixels to see that level of detail. https

• leeoniya 7y ago
  i had a prototype using https://github.com/mourner/simplify-js https://github.com/mourner/simplify-js and it did a bit better in low quality/low precision mode, but worse in high quality mode. at some point the trade-off is probably worth it but i've noticed some not-so-great artifacts even in hq mode, so had to ditch it. another major reason for ditching it is that all the series must be x-value-coalesced, so it's impossible to remove/merge datapoints along any single x without incorrectly removing/merging them in an unrelated y. since the path is drawn directly from the data without any intermediate data->path conversions & allocations, i dont think there will be a reasonable point at which general path simplification would provide a net positive. i'm pretty sure dygraphs does some form of simplification which seems to render well, but overall it ends up slower (not necessarily due to this, but did not check). it was also written at a time when Canvas was not as fast as it is today, so maybe it made more sense back then.
  • 1wheel 7y ago
    Interesting! I wonder if anyone has worked on simplification for when we know x is monotonically increasing. One really simple idea: group points by their x pixel, connecting the max and min y values for each with a vertical line.
    • leeoniya 7y ago
      uPlot requires a csv-like data structure as seen at the top of https://jsfiddle.net/v439aL1k/ https://jsfiddle.net/v439aL1k/ feel free to experiment, but i suspect that any workable solution is not going to be cheap enough and is likely to not be simple and high quality. you must be able to simplify each data series as a stream (during the path drawing loop itself) rather than allocating another set of 3 x 50,000-element pixel offset arrays, which will eat up all the benefit very quickly.
      • 1wheel 7y ago
        Twice as fast! You might be able to get interactive dragging working with this. https://bl.ocks.org/1wheel/0e7f71ac0325b9be92c9dd19fe4bcc44 https://bl.ocks.org/1wheel/0e7f71ac0325b9be92c9dd19fe4bcc44
        • leeoniya 7y ago
          interesting. it looks less accurate tho. also, i cannot use this without supporting data gaps and sparse data. it could be worse when you get it to do everything it needs to without just having this case be a dedicated additional code path. once your neat uniform loops start branching, perf usually takes a nose dive. im on a phone, but will look into it later, thanks! if you want to open an issue in the repo to work on porting this to the lib for actual apples-to-apples comparison, that would be cool, too :)
          • 1wheel 7y ago
            The column version looks like it has less detail along the top of the plot, but I think that's a rendering bug with the moveTo version: there aren't any data points above 1. I added code for gaps. The tight loop isn't disrupted that much; the number of interruptions is bounded by the x resolution. added a placeholder issue https://github.com/leeoniya/uPlot/issues/15 https://github.com/leeoniya/uPlot/issues/15
            • leeoniya 7y ago
              awesome, thanks!