You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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:
We keep the system as is.
We carry over information from arbitrary timestamps.
We let the users decide what they want (hard to explain) and provide sensible defaults.
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).
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.
The text was updated successfully, but these errors were encountered:
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:
0.21
release.The text was updated successfully, but these errors were encountered: