Tracking Issue for timing report SVG render backend

[weihanglo]

See call for testing

---

Summary

Original issue: #8850
Implementation: #15091

This changes Cargo timing report renderer from HTML canvas to SVG, improving the performance of rendering large dependency graph, as well as hovering dependency lines.

Currently canvas is still the default, and there is a toggle switching between them during the call-for-testing period

Unresolved Issues

• Call-for-testing
• Remove legacy canvas renderer
• Understand our minimum supported browser version
  • Safari 12 on an old Intel Macbook running macOS 10.12 Tracking Issue for timing report SVG render backend #16440 (comment)

Future Extensions

• A detailed view when hover on dependency lines: Experiment: Render timing pipeline in SVG #15091 (comment)
• Text selection: Tracking Issue for timing report SVG render backend #16440 (comment)
• Switch to HTML template library for better maintainability?
• Switch to a frontend framework for better maintainability?

About tracking issues

Tracking issues are used to record the overall progress of implementation.
They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions.
A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature.
Instead, open a dedicated issue for the specific matter and add the relevant feature gate label.

[eth3lbert]

I've experimented with a simple detail view as shown below:

The content and style of the details can be adjusted based on any feedback provided. Hopefully, this will mitigate the inconvenience for those who need to track 'unblocked' or 'unblocked-by' units in a large graph.

[eth3lbert]

Regarding the issue described in #15091 (comment), another idea is to introduce a dep-line lock mode. Specifically, when a unit is clicked, we would only highlight its dep-lines, even if the user hovers over other units. This should help mitigate the issue, although I'm not sure if it would be useful in the end. 🤔

[weihanglo]

Call for testing

We'd love your help testing the new SVG renderer for Cargo's timing report!

How to Test

0. Have Rust 1.92-nightly toolchain 2025-12-28 or newer
1. Run cargo build --timings
2. Open the generated cargo-timing. html file in your browser
3. Use the toggle button to switch between Canvas (legacy) and SVG (new) renderers
4. Test with projects of varying sizes (small, medium, large dependency graphs)

Feedback we're Looking For

• Performance: Does the SVG renderer feel faster, especially with large dependency graphs?
• Hovering: How responsive is hovering over dependency lines compared to Canvas?
• Low-end machines: How does it perform on older/less powerful hardware?
• Older browsers: Does it work correctly on older browser versions you may have?
• Rendering quality: Any visual differences or issues?

Please share your experience, project size (number of dependencies), and browser info. Thanks!

@rustbot label +call-for-testing +S-waiting-on-feedback

[svix-jplatte]

SVG hover seems to work better than the canvas implementation. Otherwise the only difference I could see was the top-right legend's border being lighter with the SVG backend (I think it looks better that way).

[svix-jplatte]

Actually, with Canvas + the unstable section-timings, I recently ran into

DOMException: CanvasRenderingContext2D.scale: Canvas exceeds max size.

The SVG backend has no issues with the same timing report, is fast to render and hover effects are instant :)

[madsmtm]

Tried it out briefly, performance and hovering feels a bit faster, though changing the min unit time to a larger value than any item took throws a RangeError: invalid array length at this line:

cargo/src/cargo/core/compiler/timings/timings.js

Line 534 in fe2f314

const path_commands = Array(units.length - 1)

[madsmtm]

Also tried in Safari 12 on an old Intel Macbook running macOS 10.12, the SVG rendering and hovering is noticeably faster (a rough estimate is that the canvas of the wgpu workspace renders in 7 secs, while the SVG renders in <0.4s).

[weihanglo]

Tried it out briefly, performance and hovering feels a bit faster, though changing the min unit time to a larger value than any item took throws a RangeError: invalid array length at this line:

cargo/src/cargo/core/compiler/timings/timings.js

Line 534 in fe2f314

const path_commands = Array(units.length - 1)

Would you mind sharing the timings HTML so we can try debugging it?

[madsmtm]

Sure! I built https://github.com/madsmtm/objc2 with cargo +nightly build --timings, and got cargo-timing.html.