We rewrote our custom visualisation renderers from SVG to be in Canvas
The engineering team replaced a legacy SVG renderer that created a DOM node for every flame‑graph frame—tens of thousands of <rect> and <text> elements—and batched updates in groups of roughly 500 to avoid freezing the UI. After parallelising the SVG draw they had already shrunk the initial render of a large query from ~8 seconds to ~91 ms, but the DOM’s inherent overhead still limited scalability. By moving the rendering to Canvas, they eliminated per‑frame objects entirely. The new pipeline receives pre‑computed frame positions via Arrow Flight in a columnar, zero‑copy format, allowing the draw loop to read raw arrays of x‑positions, widths, and depths and issue a single fillRect or fillText call per visible frame. With viewport culling, only the ~800 frames that fit on screen out of a 50 k‑frame profile are drawn, turning a potentially massive DOM tree into a handful of immediate draw commands. This redesign also makes zooming and scrolling instantaneous because the canvas is sized only slightly larger than the viewport and existing pixels are shifted rather than redrawn, while zoom simply rescales the already‑computed coordinates.
The shift mirrors a broader industry move toward immediate‑mode graphics for data‑intensive web UIs. Tools such as Chrome DevTools, Firefox Profiler, and third‑party services like Datadog and New Relic have all experimented with Canvas or WebGL to render large timelines, recognizing that retained‑mode DOM trees become a bottleneck once element counts exceed a few thousand. Leveraging Rust for the query engine and Apache Arrow for columnar transport aligns with the growing adoption of low‑level, zero‑copy data pipelines in observability platforms, where the cost of moving data often outweighs compute. By decoupling layout computation from the browser and delivering render‑ready tables, the team sidesteps both JavaScript GC pressure and the browser’s layout engine, a pattern increasingly seen in high‑performance telemetry dashboards.
The immediate gains are clear—sub‑millisecond interaction latency and dramatically lower memory churn—but the Canvas approach also introduces new constraints. Without a DOM representation, features like accessibility hooks, element‑level event handling, or CSS‑based theming become more complex. Future scaling may push the team toward GPU‑accelerated rendering (e.g., WebGL or WebGPU) to handle even larger profiles or richer visualisations. Monitoring how the canvas implementation handles extreme data volumes, cross‑browser consistency, and integration with existing UI frameworks will be critical as the product evolves.
Key Takeaways
Replacing SVG with Canvas removed the need for tens of thousands of DOM nodes, turning a multi‑second render into an instantaneous one.
Streaming pre‑computed frame geometry as columnar Arrow data enabled zero‑copy reads and a trivial draw loop.
Viewport culling on the canvas reduced draw calls from the total frame count to only those visible, e.g., ~800 of 50 k frames.
While performance improves, the loss of a
About the Source
This analysis is based on reporting by Hacker News. Here is a short excerpt for context:
CommentsRead the original at Hacker News