Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Carry over graph layout information between time points #8282

Closed
Tracked by #7897
grtlr opened this issue Dec 2, 2024 · 0 comments · Fixed by #8308
Closed
Tracked by #7897

Carry over graph layout information between time points #8282

grtlr opened this issue Dec 2, 2024 · 0 comments · Fixed by #8308
Assignees
Labels
feat-graph-view Everything related to the graph view

Comments

@grtlr
Copy link
Contributor

grtlr commented Dec 2, 2024

Here is a writeup of a discussion that I had with @abey79, but it's very important that we make a decision on this for the 0.21 release.

Currently, the graph viewer performs one layout step per frame of the UI, optionally requesting new frames until the layout is finished.

As it is right now, if input data changes (from example because the user scrubs the timeline) we completely reset the layout and start from scratch. Doing so has one big advantage: it allows us to have deterministic layouts, i.e. if the user navigates to a given timestamp she is guaranteed to get the same layout every time.

The downside of this is that, depending on the scrubbing speed (or the playback speed of the recording) the user will only see the gibberish of the initial layout steps:

Screen.Recording.2024-12-02.at.17.18.38.mov

Also, for some graphs (like the one above) the resulting visualization (and final layout) will be much clearer if we consider the previous state of the visualization. Here you can see an example of this (same recording with slower playback speed):

Screen.Recording.2024-12-02.at.17.22.04.mov

Note how for each new timestamp the entire graph glitches. This would be solved by retaining some layout information and the results would look much nicer.

The big downside of carrying over information from arbitrary steps of the time is that we become much less predictable: The way the graph looks now depends on the history of user interactions (@emilk I wonder how that works with undo, as we don't currently write back the layout information).

I'm wondering how much the determinism is worth to us?

We now have a choice to make:

  1. We keep the system as is.
  2. We carry over information from arbitrary timestamps.
  3. We let the users decide what they want (hard to explain) and provide sensible defaults.
  4. We only carry information over from "adjacent" timestamps to make the system less indeterministic (I don't know if we have a way to query that, probably using ranges).
  5. We implement full time-traveling by keeping all previous (relevant) layout steps. A lot of work and out-of-scope for a 0.21 release.
@emilk emilk added the feat-graph-view Everything related to the graph view label Dec 4, 2024
@grtlr grtlr self-assigned this Dec 4, 2024
@grtlr grtlr closed this as completed in c0fad11 Dec 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feat-graph-view Everything related to the graph view
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants