Avoid rendering Gizmo multiple times on rotate

[mmisol]

Purpose

This PR aims to fix the problem described in the title, which occurs in the helix-upgrade branch.

When a Point.ByCoordinates node is placed on the canvas with some unfilled input this triggers the directManipulation extension to draw gizmos that let the user manipulate this point in space directly. When the user rotates the camera when the point node is still selected and the gizmos are drawn the performance is terrible, and the camera cannot be rotated smoothly.
 

The issue is caused by a change of behavior in helix when upgrading from v2015 is that the CameraChanged event gets fired several times, once for each individual property of Camera that changed.

In order to avoid rendering the Gizmo several times, which leads to choppy camera rotation, we limit the rendering of the Gizmo to only be done when the position of the camera changed.

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.

Reviewers

@mjkkirschner @aparajit-pratap

[mjkkirschner]

hmm
https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.media3d.point3d.op_equality?view=netframework-4.8#System_Windows_Media_Media3D_Point3D_op_Equality_System_Windows_Media_Media3D_Point3D_System_Windows_Media_Media3D_Point3D_

or is this a SharpDX point3d?

do you think it's worth to do an epsilon tolerant equals?

[mjkkirschner]

this is what I'm referring to:

Two Point3D structures are equal if the values of their X, Y , and Z properties are the same.

Because Double values can lose precision when arithmetic operations are performed on them, a comparison between two Point3D instances that are logically equal might fail.

[mmisol]

Due to the nature of the issue, there shouldn't be a need to be epsilon tolerant. Basically what's happening is:

1. Camera.LookDirection is set -> OnViewCameraChanged (ignored as Position is same)
2. Camera.Position is set -> OnViewCameraChanged (not ignored as Position is different)
3. Camera.UpDirection is set -> OnViewCameraChanged (ignored as Position is same)

[QilongTang]

Would the default Equals sufficient? https://docs.microsoft.com/en-us/dotnet/api/system.windows.media.media3d.point3d.equals?view=netframework-4.8#System_Windows_Media_Media3D_Point3D_Equals_System_Object_

[mmisol]

@QilongTang Yes, we are ignoring case 1 and 3 in my post above by using (X, Y, Z) equality. The == operator is overloaded to behave exactly as Equals.

[mjkkirschner]

cool, thanks for the explanation @mmisol

[QilongTang]

Good improvement! LGTM

[aparajit-pratap]

@mmisol thanks for the fix! I'm sure you also manually tested that the gizmo size is invariant with zoom.

[aparajit-pratap]

BTW, just curious, do you have screenshots of the dot trace profiling before and after the helix update?

[mmisol]

@aparajit-pratap I did not take a screenshot, sorry

[mjkkirschner]

you may be able to find the session here: C:\Users\[username]\AppData\Local\JetBrains\dotMemory\[version]\Workspaces - useful anyway to check because sometimes they take a bunch of hd space.