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
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
First of all, task name is not accurate because geometry is fully rendered after some time.
When there is a lot of geometry, Dynamo computes and renders it quite slowly. The PR adds some optimization to partly overcome the issue:
SceneItems is constantly being called, so each time it generates new list and sorts it.
In this PR SceneItems is computed only after changes in its source;
To implement label behavior it had stored graphic array items separately to have an ability to find an array item by index (geometry doesn't know which node array item it belongs to) and such solution had slowed down rendering.
In this PR node array geometry items are stored together as it had used to be and instead label positions are stored in a separate place, so when a node requests displaying label for its array item we know where to place the label.
Analysis
I made a competition between Dynamo without my changes and Dynamo with them. It was used lotsofstuff.dyn from the task.
when code block value is 0..10..2:
Render time for each node means time to generate geometry objects from render packages for the node. setting properties and rendering time means time to render already generated geometry. Render packages for each node are coming separately and between receiving packages, Helix renders what it already has. sum time means time passed from receiving the very first render packages to finishing render of all geometry.
So, it this case we have 9 seconds of gain in time.
when code block value is 0..20..2:
In this case designations are the same, code block just gives much more array items, we have 1 minute and 19 seconds of gain in time.
These time values are got from output window in Visual Studio. Also, I noted the time on my smartphone starting at pressing Run button and stopping at all geometry appears. The results are next:
when code block value is 0..15..2, not optimized Dynamo takes 1 minute and 45 seconds and optimized Dynamo takes only 40 seconds, so gain in time is 1 minute and 5 seconds;
when code block value is 0..20..2, not optimized Dynamo takes 3 minutes and 20 seconds and optimized Dynamo takes 1 minute and 44 seconds, so gain in time is 1 minute and 36 seconds;
By the way computing render packages for a node with many array items is time-consuming operation as well. The PR does not consider this component of the delay in rendering
The reason will be displayed to describe this comment to others. Learn more.
@marimano Are we just fixing the test to match the behavior here, or have the changes you made actually result in there being less objects in the scene?
The reason will be displayed to describe this comment to others. Learn more.
@ikeough these changes in tests are done to match new behavior which is presented in this PR. All points of a node are stored in a single geomentry instead of storing each array item of the node separately. So, here are 6 points which are stored in 1 PointGeometryModel3D from now
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Purpose
First of all, task name is not accurate because geometry is fully rendered after some time.
When there is a lot of geometry, Dynamo computes and renders it quite slowly. The PR adds some optimization to partly overcome the issue:
SceneItems
is constantly being called, so each time it generates new list and sorts it.In this PR
SceneItems
is computed only after changes in its source;In this PR node array geometry items are stored together as it had used to be and instead label positions are stored in a separate place, so when a node requests displaying label for its array item we know where to place the label.
Analysis
I made a competition between Dynamo without my changes and Dynamo with them. It was used
lotsofstuff.dyn
from the task.Render time for each node means time to generate geometry objects from render packages for the node.
setting properties and rendering time
means time to render already generated geometry. Render packages for each node are coming separately and between receiving packages, Helix renders what it already has.sum
time means time passed from receiving the very first render packages to finishing render of all geometry.So, it this case we have 9 seconds of gain in time.
In this case designations are the same, code block just gives much more array items, we have 1 minute and 19 seconds of gain in time.
These time values are got from output window in Visual Studio. Also, I noted the time on my smartphone starting at pressing Run button and stopping at all geometry appears. The results are next:
By the way computing render packages for a node with many array items is time-consuming operation as well. The PR does not consider this component of the delay in rendering
Declarations
*.resx
filesReviewers
@mjkkirschner
FYIs
@jnealb @kronz @ikeough