mui
[charts] Provide WebGL based implementation?
Summary
The charts are implemented with SVG today. In the future, we could consider WebGL as a rendering target to improve the performance with large datasets #12960. Now, we would need to make sure that we can't improve SVG anymore, and it's not good enough, until it makes sense to go down this path.
In practice, this would impose strong API constraints; developers would most likely not be able to use the decomposition API, and they would have to stick with a top-level closed component API.
Before, we need to weigh the pros and cons of #18015.
Examples
- highcharts: SVG + WebGL https://www.highcharts.com/docs/advanced-chart-features/boost-module
- SciChart: WebGL only https://www.scichart.com/blog/the-best-javascript-chart-10-reasons/
- LightningChart: WebGL https://lightningchart.com/js-charts/
Motivation
No response
Search keywords: -
May I ask why WebGL and not the newer WebGPU?
I guess it depends on when (if we ever do) work on this. Today, WebGPU is not usable in production because browser support: https://developer.mozilla.org/en-US/docs/Web/API/WebGPU_API#browser_compatibility, but in theory, we should be able to, at one point.
Having worked with the webgl/webgpu APIs, I think it's a big effort for not that big of a payoff compared to a properly optimized canvas 2d-context implementation. The APIs are much more C-like (or Rust-like for WebGPU) than the usual browser API is. But for anyone interested in going down this path, this is the best starting resource by far: https://webglfundamentals.org.
WebGPU might be good in the future, but WebGL is still the only widely supported solution and is here to stay anyway. Perf-wise the APIs are equivalent for simple cases. WebGPU's compute API is nice in that it avoid having to do everything from a 3d-renderer's lens, but anyone who deals with GPU needs to understand the 3d-rendering model anyway, so not really a win.
Apparently, there's a limit of WebGL contexts that can exist simultaneously (source), and it seems to be a limit per origin, not per tab. If you have 4 tabs of the same website open, you can only show 4 charts per tab, unless you share the context (which I'm not sure how feasible/easy it is do).
Indeed, one of the reasons I list for using canvas in the pencil experiment. WebGL is rarely worth it outside of 3d rendering.
SciChart claim they use WASM + WebGL (source), but they render to a canvas and mention that they don't suffer from the WebGL context limit, so it must be possible to reuse the context somehow.
You can draw anything you want on a WebGL context, so they probably draw multiple charts per context and slice the image buffer into separate containers after it's been drawn. For them it makes sense to do the investment, they target the very high-end custom charts market and they can afford the engineering time required to make it all work. There's a lot of technical depth required to use WASM + WebGL. But using a solution like that for any sort of chart is definitely overkill, both in pricing and in device resources. Canvas is more versatile, it can be used to draw tons of small charts (think trend lines in an analytics or fintech dashboard), and it can also be used to draw complex interactive charts. WebGL will have an edge in the latter use-case, but for the average charting needs (that x-charts imo targets), canvas is enough.
Some thoughts:
- Currently, chart export works by creating a canvas out of SVG and exporting it. Can we transform WebGL into a canvas or obtain a PNG out of a WebGL context?