161–170 of 226 posts
Very cool, I like the variety of demos! On the candle sticks streaming demo ( https://chartgpu.github.io/ChartGPU/examples/candlestick-str... ), the 1s/5m/15m etc buttons don't seem to do anything
Good catch! Thanks for actually clicking around and finding this - added to my issue tracker.
Earlier quoted context omitted.
Is there any techniques using wavelet decomposition to decimate the high frequency component while retaining peaks? I feel like that's a more principled approach than sampling but I haven't seen any literature on it describing the specific techniques (unless the idea is fundamentally unsound which is not obvious to me).
Interesting idea - I haven't explored wavelet-based approaches but the intuition makes sense: decompose into frequency bands, keep the low-frequency trend, and selectively preserve high-frequency peaks that exceed some threshold. My concern would be computational cost for real-time/streaming use cases. LTTB is O(n) and pretty cache-friendly. Wavelet transforms are more expensive, though maybe a GPU compute shader cou…
You can now render up to 5 million candles. Just tested it - Achieved 104 FPS with 5M candles streaming at 20 ticks/second.
Demo: https://chartgpu.github.io/ChartGPU/examples/candlestick-str...
Also fixed from earlier suggestions and feedback as noted before:
- Data zoom slider bug has been fixed (no longer snapping to the left or right) - Idle CPU usage bug (added user controls along with more clarity to 1M point benchmark)
13 hours on the front page, 140+ comments and we're incorporating feedback as it comes in.
This is why HN is the best place to launch. Thanks everyone :)
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…
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…
I wouldn't spend too much of your time deep diving - it's an AI slop project.
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…
Original Flot maintainer here. I once had to deal with many million data points for an application. I ended up mip-mapping them client-side. But regarding sampling, if it's a line chart, you can sample adaptively by checking whether the next point makes a meaningfully visible difference measured in pixels compared to its neighbours. When you tune it correctly, you can drop most points without the difference being not…
I discovered flot during my academic research career circa 2008 and it saved my ass more times than I can count. I just wanted to say thank you for that. I wouldn't be where I am today without your help :)
Earlier quoted context omitted.
At 1M points it hardly makes a difference. Besides, 1 point -> 1 pixel mapping is good enough for a demo, but in practice it will produce nasty aliasing artifacts because real datasets aren't aligned with pixel coordinates. So you have to draw each point as a 2x2 square at least with precise shading, and we are back to the rasterizer pipeline. Edit: what actually needs to be computed is the integral of the points dat…
Aren't we at petaflops now with GPUs? 1M or even 1G points should be no issue if it renders to a framebuffer and doesn't go through mountains af JS framework rubbish followed by mountains of GTK/Qt/.NET rubbish.
There is this misconception that if one uses js or c# to tell a gpu what to do it is somehow slower than rust. It only is if you crunching data but moving memory to the gpu and telling gpu to crunch is virtually identical.
What's the best way to get all those points from a backend into the frontend webgpu compute shader? There doesn't seem to be a communication mechanism that has minimal memcopy or no serialization/deserialization, the security boundary makes this difficult. I have a backend array of 10M i16 points, I want to get this into the frontend (with scale & offset data provided via side channel to the compute shader). As it st…
For this, compression/quantize numbers and then pass that directly to the gpu after it comes off the network. Have a compute shader on the gpu decompress before writing to a frame buffer. This is what high performance lidar streaming renderers do as lidar data is packed efficiently for transport.
Earlier quoted context omitted.
Thanks! Leon's uPlot is fantastic - definitely an inspiration. Worker thread support via OffscreenCanvas is a great idea and WebGPU does support it. I haven't tested ChartGPU in a worker context yet, but the architecture should be compatible - we don't rely on DOM for rendering, only for the HTML overlay elements (tooltips, axis labels, legend). The main work would be: 1. Passing the OffscreenCanvas to the worker 2.…
You have a good point about doing zero copy transferables which would probably work. There is certainly something beautiful about your charging GPU code being part of a file that runs completely isolated in another thread along with our websocket Data fire hose Architecturally that could be something interesting where you expose a typed API wrapping postmessage where consumers wanting to bind the main thread to a wor…
The code in the repo is pretty awful with zero abstraction of duplicated render pipeline building and ai slop comments all over the place like “last resort do this”. Do not use this for production code. Instead, prompt the ai yourself and use your own slop.
The performance here is also terrible given it is gpu based. A gpu based renderer done correctly should be able to hit 50-100m blocks/lines etc at 60fps zoom/panning.
It is a testament to how good ai is though and the power of the dunning kruger effect