Pivot ApexCharts to ChartGPU and deck.gl

[bluelightspirit]

Non-GPU based JS chart libraries are quite slow per https://github.com/abtsoftware/javascript-chart-performance-test-suite
deck.gl is good for the geographic side it seems since the README says "deck.gl maps data (usually an array of JSON objects) into a stack of visual layers - e.g. icons, polygons, texts; and look at them with views: e.g. map, first-person, orthographic" while charts/graphs appear to be more on ChartGPU's focus.

SciChart and LCJS may be the fastest 2 JS chart libraries, but they are closed source. ChartGPU and deck.gl are open source.

On a side note, it would be interesting if SQLPage were to work with Super Sirius DB while using ChartGPU - just integrating with the graphics card as much as possible. However, I have not tested Sirius in SQLPage yet. Was curious of your thoughts from the ApexCharts pivot. The issue is when there are millions of points to consider rather than maybe like up to 100,000.

Should SQLPage switch from ApexCharts to ChartGPU and deck.gl?

[bluelightspirit]

https://github.com/leeoniya/uPlot#performance - some more benchmarks are here to show ApexCharts being slow.

https://lightningchart.com/blog/7-best-apexcharts-alternatives-in-2026/ - ECharts with WebGL extension may be competitive?

[bluelightspirit]

Lumen Charts - https://github.com/jagtesh/lumen-charts#api-completeness seems to be an alternative to any JS charting engines as it is straight from Rust to WASM it seems and appears to be equivalent to Lightweight Charts. https://github.com/cloud-shuttle/leptos-helios exists too though the README does not seem as battle tested as Lumen Charts. Though, 80ms for 1M points Leptos Helios claims may show it is better than SciChart and LCJS in some cases - I don't know for sure though, and in reality, I'd assume 80ms is equivalent to 12.50 FPS per https://github.com/abtsoftware/javascript-chart-performance-test-suite at 1M points - well, then Leptos Helios is just a ChartGPU competitor at that point. https://github.com/monapochi/mochart - Mochart is iffy per the licensing stuff at the bottom but it says the licensing rules aren't enforced yet in alpha it seems? 60 FPS for 1M points does beat SciChart and LCJS in some cases if the 60 FPS were to be consistent in all tests.

https://geobench.johncarmack.com/ is interesting - apparently someone figured out how to make DuckDB be embedded (Rust side of Tauri) — no network, no serialization. PMTiles is a single file, range-read off disk/CDN — no tile server. https://github.com/maplibre/maplibre-gl-js also may be competitive in the geospatial world.

I also found a Sirius DB alternative - this one supports Mac GPU it seems? https://github.com/singhpratech/duckdbgpumetaldbram - interesting.

[bluelightspirit]

I will say https://gitlab.com/IvanSanchez/gleo which appears to be a WIP says it aims to have "An API that feels like Leaflet" per https://ivansanchez.gitlab.io/gleo/ however the GitLab README also says "It aims to cover the use cases of Leaflet, OpenLayers or MapboxGL/MaplibreGL, but since it's a one-man project, it's not quite there yet." - deck.gl/OpenLayers/MapLibre seem quite time consuming to integrate to in theory versus gleo from Leaflet.

[bluelightspirit]

Also instead of making up numbers for the GIS side here is https://www.pistack.xyz/posts/2026-06-15-self-hosted-web-mapping-libraries-leaflet-openlayers-maplibre/ saying MapLibre GL JS is about 3x faster than Leaflet in FPS for rendering 10,000+ vector features.

https://advena.hashnode.dev/heavy-map-visualizations-fundamentals-for-web-developers exists - yeah um, GIS is, quite time consuming to learn it seems. Cesium vs deck.gl is a whole nother story per https://matom.ai/insights/cesium-vs-deck-gl/ and https://js-maps.com/best-javascript-map-libraries/ though... both of which do render in WebGL.

Hi @bluelightspirit, thanks for taking the time to look into these options and share them.

For suggestions like these to be most useful to the project, it would help if they were based on hands-on experience with SQLPage and a concrete use case. That gives us a better basis for evaluating whether a library or approach would actually be a good fit.

If you have a real scenario where you need to render millions of data points with very low latency, we’d be happy to look at it with you and see what improvements might make sense.

In the meantime, I’d suggest trying some of these libraries in practice before recommending them, since benchmarks and project homepages don’t always reflect real world usage characteristics.