Experiment: Render timing pipeline in SVG

[eth3lbert]

What does this PR try to resolve?

This PR adds an SVG renderer and allows users to choose between Canvas and SVG for rendering charts, which should hopefully resolve #8850.

Additional information

This does not guarantee a pixel-perfect match from the previous canvas-based solution, but I maintain it stays as close as possible.

[rustbot]

r? @weihanglo

rustbot has assigned @weihanglo.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[ehuss]

For context, the original version of this used SVG. However, it was switched to canvas due to severe rendering performance problems on some systems and browsers. Has this been thoroughly tested on multiple browsers, and on systems with limited video cards, and different platforms?

[eth3lbert]

For context, the original version of this used SVG.

Yeah, I noticed this part.

Has this been thoroughly tested on multiple browsers, and on systems with limited video cards, and different platforms?

No, I haven't tested it with legacy devices or systems, only the newest Firefox and Chrome. Testers and feedback are welcome :D

[weihanglo]

However, it was switched to canvas due to severe rendering performance problems on some systems and browsers

Any chance to recall those legacy systems and browsers?

[ehuss]

Any chance to recall those legacy systems and browsers?

It was probably a 2018-era Intel integrated UHD Graphics 630 or AMD Radeon Pro 560X with an Intel Core i7 (macbook). I think Firefox was one of the worst in performance, but Safari and Chrome were also pretty bad. I believe Firefox has improved its SVG rendering since then.

[eth3lbert]

I believe Firefox has improved its SVG rendering since then.

For Firefox, although the SVG renders without issues, I encountered significant frame drops while scrolling on an M1 device when experimenting with this SVG solution for crates.io (which has 619 units in total). This is primarily due to those dependency lines. If I hide those dependency lines, everything works fine.

I'm not sure if this performance issue is solvable without modifying the presentation. If we only rendered dependency lines for on-screen blocks, the performance would improve significantly, although I'm not sure if this approach is desirable.

[weihanglo]

@eth3lbert are you still interested in the experiment? Should we continue from here or write down a summary in #8850?

@rustbot author

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[eth3lbert]

@eth3lbert are you still interested in the experiment? Should we continue from here or write down a summary in #8850?

@rustbot author

Yes, still interesting! But I am wondering if implementing this using the interactive approach, as mentioned in the #8850 (comment) would be more appropriate:

There are existing tools that use both approaches. For example, FlameGraph uses an SVG, and speedscope uses an interactive canvas interface.

Specifically, we could restrict the width and height and provide pan and zoom functionality (which could be implemented using either canvas or SVG). Furthermore, we could also provide the ability to change the size and add search functionality if needed. This approach would restrict memory usage to an acceptable level and potentially further improve performance. The drawback might be that users with large screens might lose the ability to view the whole graph at once and would need to zoom in. We could also provide a graph export ability for those interested in the entire graph. This, however, would change how the graph is shown and interacted with, and I am unsure if this aligns with the goal. Feedback is welcome! :D

[weihanglo]

The drawback might be that users with large screens might lose the ability to view the whole graph at once and would need to zoom in.

This reminds me a property we discussed a while back (#t-cargo > ✔ Making timings chart scalable @ 💬): it is possible to set two different timings charts to identical scales for comparison. Not sure if the proposal will remove this or not.

That said, it might be a bit easier to implement now since the RenderContext provide an separation of data and presentation layer: #16282. We could probably have an unstable SVG timing report format for people to test :)

[weihanglo]

Or we could have a button for people to switch between two modes 😆

[eth3lbert]

That said, it might be a bit easier to implement now since the RenderContext provide an separation of data and presentation layer: #16282. We could probably have an unstable SVG timing report format for people to test :)

Thanks for the information, I'll take a look in the near future :D

Or we could have a button for people to switch between two modes 😆

Is this referring to canvas and SVG rendering, or to panning and zooming?

[weihanglo]

For switching between SVG/canvas, but could also for other stuff. This is not strictly adhered with Cargo's stability guarantee I believe.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[eth3lbert]

For switching between SVG/canvas

I've added this now! The CI failed, but it shouldn't be related to this PR. The scrolling jank in Firefox is also fixed on my end, so please give it a try and let me know what you think. :D

[eth3lbert]

I also found that highlighting connected units on hover is less useful when there are many units. They might not all fit on the screen, which means you have to scroll a long way to find the connections. Plus, you might accidentally hover over other units while scrolling. Because of this, a different interface would be more helpful for showing these relations. For example, clicking a unit to show its connections in a side panel might provide a better UX.

[weihanglo]

Windows GNU flakiness. Re-running

---- freshness_checksum::no_rebuild_when_rename_dir stdout ----
running `D:\a\cargo\cargo\target\debug\cargo.exe build -Zchecksum-freshness`

thread 'freshness_checksum::no_rebuild_when_rename_dir' (8768) panicked at tests\testsuite\freshness_checksum.rs:1148:32:
> called `Result::unwrap()` on an `Err` value: Os { code: 5, kind: PermissionDenied, message: "Access is denied." }

[eth3lbert]

I plan to make the SVG renderer the default, since it outperformed Canvas in my testing across Firefox, Chrome, and Safari!

[weihanglo]

Tested and really really impressive!

#15091 (comment)

[weihanglo]

Thanks for working on this. The PR is so nice for both refactors and the SVG implementation.

I assume this doesn't need any team FCP:

• It offers a switch between canvas and SVG rendering options. If anything broken, people can always switch back.
• The default is still canvas.
• The HTML report UI is for human not for machine, so we have more flexibility to change it.

I am excited to merge this right now! Really appreciate it!

View changes since this review

[weihanglo]

I also found that highlighting connected units on hover is less useful when there are many units. They might not all fit on the screen, which means you have to scroll a long way to find the connections. Plus, you might accidentally hover over other units while scrolling. Because of this, a different interface would be more helpful for showing these relations. For example, clicking a unit to show its connections in a side panel might provide a better UX.

Agree with side panel solution. That sounds pretty approachable.
I am not sure if it is easy to implement though, as currently we don't use any Web Frontend frame work, which may make it a bit hard to maintain

[weihanglo]

I just tried with CARGO_BUILD_ANALYSIS_ENABLED=true rustup run nightly target/debug/cargo build -Zsection-timings -Zbuild-analysis && target/debug/cargo report timings -Zbuild-analysis --open. The performance enhancement was so huge!

• Google Chrome: Version 143.0.7499.170 (Official Build) (arm64)
• Safari: Version 26.2 (20623.1.14.18.4)
• Firefox: 145.0 (aarch64)

1. Tried set the scale factor to 9.
2. Chose the canvas renderer
   • Observed on Chrome and Safari, it was laggy and stopped rendering at some point.
   • Observed on Firefox it worked.
3. Switched to the SVG renderer
   • All of them works well.
   • On Firefox the dependency line drawing was faster than the canvas renderer.

Here is the timing HTML: cargo-timing.html