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

WIP: Defer node view loading to speed up opening times (and possibly UX) of large graphs. #15784

Open
wants to merge 7 commits into
base: master
Choose a base branch
from

Conversation

dimven-adsk
Copy link
Contributor

@dimven-adsk dimven-adsk commented Jan 27, 2025

Purpose

This PR is similar in idea to what Bogdan proposed here, but tackles the problem from the xaml, instead of the code-behind. That way we don't have to make any changes to the node content.


Instantiating the node views is a very large chunk of the overall graph loading times (from starting to parse the json to rendering the content and having Dynamo respond to user input). It scales disproportionately to the number of nodes, such as with the more nodes you have, the greater the percentage of time it eats up. On the MaRS graph, with about 700 nodes, it roughly takes a quarter of the time:

devenv_iboFFF1e2N

Unfortunately, we can't do much about this, other than to delay the loading until it's absolutely needed. By default this PR will only display the nodes and annotations that are in the visible portion of the graph and load their view, when they first become visible:

RYLD7BSWvj

This greatly speeds up the loading times, but the new problem with this approach, is that if you pan/zoom the view and all of a sudden a lot of nodes become visible at the same time, the UI thread will freeze until they are loaded. Again, this doesn't get rid of the problem, it just breaks it down into smaller chunks :D

Current graph loading and navigation:
DynamoSandbox_wihtwgprbS

Deferred graph loading and navigation:
DynamoSandbox_k03eBXOnM0

I think that this method has a lot of value. However, I've been struggling with it for a while and I haven't come up with a good way of reducing the UI freeze :/

I'm hoping you can take a look and propose some new ideas.

"Collapsing" the hidden workspace elements, should also improve the overall navigation performance, because we have less controls to load and render, less pixels to paint, less objects to participate in hit tests, etc. However I don't have a good way of measuring that. Using the application timeline captures some of this, but is very hard to compare between multiple timelines.

Declarations

Check these if you believe they are true

  • The codebase is in a better state after this PR
  • Is documented according to the standards
  • The level of testing this PR includes is appropriate
  • User facing strings, if any, are extracted into *.resx files
  • All tests pass using the self-service CI.
  • Snapshot of UI changes, if any.
  • Changes to the API follow Semantic Versioning and are documented in the API Changes document.
  • This PR modifies some build requirements and the readme is updated
  • This PR contains no files larger than 50 MB

Release Notes

(FILL ME IN) Brief description of the fix / enhancement. Use N/A to indicate that the changes in this pull request do not apply to Release Notes. Mandatory section

Reviewers

(FILL ME IN) Reviewer 1 (If possible, assign the Reviewer for the PR)
@mjkkirschner , @pinzart90

(FILL ME IN, optional) Any additional notes to reviewers or testers.

FYIs

(FILL ME IN, Optional) Names of anyone else you wish to be notified of

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants