uPlot

Intentionally not edited to add: Why are you using minified dependencies (like uPlot.iife.min.js[1] and uPlot.min.css[2]) for a desktop application? uPlot is also open source (released by Sorokin under MIT), but why aren't you following the terms of its license[3]? 1. <https://github.com/obdev/littlesnitch-linux/blob/main/webroo...> 2. <https://github.com/obdev/littlesnitch-linux/blob/main/webroo...> 3. <https://github.com/leeoniya/uPlot/blob/master/LICENSE>

> In Ardour (a cross-platform, libre, open source DAW), we actually compute and store min/max-per-N-samples and use that for plotting (and as the basis for further downsampling. this is, effectively, what uPlot does, too: https://github.com/leeoniya/uPlot/issues/1119

uPlot maintainer here. this looks interesting, i'll do a deeper dive soon :) some notes from a very brief look at the 1M demo: - sampling has a risk of eliminating important peaks, uPlot does not do it, so for apples-to-apples perf comparison you have to turn that off. see https://github.com/leeoniya/uPlot/pull/1025 for more details on the drawbacks of LTTB - when doing nothing / idle, there is significant cpu being used, while canvas-based solutions will use zero cpu when the chart is not actively being updated (with new data or scale limits). i think this can probably be resolved in the WebGPU case with some additional code that pauses the updates. - creating multiple charts on the same page with GL (e.g. dashboard) has historically been limited by the fact that Chrome is capped at 16 active GL contexts that can be acquired simultaneous

related: i had to jump through the Date hoops recently (again) when rewriting uPlot's DST and timezone handling, but i'm pretty happy with the result that avoided much complexity, performance loss, and adding a dependency: https://github.com/leeoniya/uPlot/pull/1072 fun demos: https://leeoniya.github.io/uPlot/demos/timezones-dst.html

the Infinity plugin is pretty awesome, free, and oss; i'm not sure this qualifies as spam, per se. nothing there requires signing up for cloud/SaaS, and you can 100% run this locally. i mean, you can always roll your own UI if that's something you prefer / can do. (grafana uses uPlot [0] if you need to render millions of points). disclaimer: i work on dataviz at grafana [0] https://github.com/leeoniya/uPlot

Thank you and the team for your hard work, and congratulations on the release! Suggestions for Demos: 1.Charting Libraries Integration There’s currently a lack of demos showcasing LiveView integrated with powerful charting libraries like Apache ECharts, Plot, Chart.js, etc. A demo of a LiveView-powered dashboard using one of these libraries, connected to a database like SQLite (for simplicity) or DuckDB (for speed and demonstrating integrations beyond Ecto-native DBs), would be fantastic. Emphasizes interactivity: For example, demonstrate how a server-based LiveView can handle actions such as mouse hover on a chart to update tooltips/labels, click-and-zoom interactions, or connected charts with brush functionality. 2.UI Component Libraries A demo showcasing robust integration with UI component libraries would also be valuable. Features li

> Not that you're asking for advice, The cunningham's-law-optimal way is to not ask, surely. Either that or the some programmers equivalent of the "death drive". > canvas Indeed, the canvas is basically inevitable, but it's a bespoke chart that has both temporal and non-temporal data in it (not sure what the terminology should be, but imagine plotting market expectations of interest rates in future and what expectations were historically displayed relative to current levels - but repeated ~200 times), so the existing chart libraries aren't particularly helpful and can get in the way of being able to click on stuff. Anecdotally I find that programmers are very good at writing charts for the kinds of data they understand (time series, time series of their stock options, etc), but even the "generic" (e.g. grammar of graphics) libraries can s

Ha, the creator of uplot strikes again! Love seeing your stuff man, always so thorough and well-explained, nice work (https://github.com/leeoniya/uPlot)

BACKEND: It's about 3000 lines of Crystal code https://crystal-lang.org/ -- it's been an absolute dream to program in. Ruby-like syntax, statically compiled performance. Nice standard library. Would recommend :) Performance == caching Local ephemeral filesystem for shortest-term caching. Redis for shared medium-term caching and locking. S3-compatible object storage for longest-term caching (for raw data feeds pulled every evening by a cronjob). FRONTEND: Bootstrap uPlot https://github.com/leeoniya/uPlot Just a sprinkle of inline JS+CSS on the page.

you can use matchMedia to detect devicePixelRatio changes and re-sync: https://github.com/leeoniya/uPlot/blob/190134aa844cfa2a0c052... everything stays crisp even as you browser-zoom. e.g. https://leeoniya.github.io/uPlot/demos/area-fill.html

one [more] thing i want is to be able to retain canvas context settings when resizing the canvas. e.g. it's unreasonably very expensive to re-sync the lost ctx.font on every dragged pixel - this operation alone dominates my perf profiles. i have no idea why it should be so expensive once the font is already loaded / cached in mem. ctx.fillText() is the next perf killer :( maybe i can sacrifice some quality for speed during resize with the new ctx.textRendering, though. ...and one more thing. why is there no easy inverse of ctx.clip(), e.g. ctx.mask()? currently i think it requires resorting to awkward Path2D composition/cloning + evenodd ctx.fill() hacks: https://github.com/leeoniya/uPlot/issues/628

Safari's slow release cadence (typically tied to OS version upgrades) does leave it more broken and for longer than Firefox, Chrome, Opera and other browsers that are updated more frequently and not tied to the OS. just recently i ran into incompatibilities with Safari < 14 needing a shim due to still having the old-spec MediaQueryList api: https://github.com/leeoniya/uPlot/issues/538#issuecomment-87...

super cool! i've done my share of optimizations and benchmarking of various charting libs [1] but this goes deeper still. SVG is not a good choice for large raw datasets when you need performance. [1] https://github.com/leeoniya/uPlot#performance