Experiment: Render timing pipeline in SVG

[eth3lbert]

What does this PR try to resolve?

This PR renders the timing pipeline in SVG, 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.

[rustbot]

☔ The latest upstream changes (possibly fa10d65) made this pull request unmergeable. Please resolve the merge conflicts.

[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 😆