DYN-6738: Fix gizmo redraw and camera drift issues #16852

jasonstratton · 2026-01-23T21:53:23Z

Summary

Fixes two issues with gizmo manipulation:

Gizmo redraw failure during drag - Fixed by adding forceAsyncCall=true parameter to ensure render operations are properly queued on the dispatcher
Camera drift when zoomed in close - Fixed by filtering mouse events (left button only) and clearing stale hit state after manipulation

Root Causes

Issue 1: Missing forceAsyncCall parameter prevented proper async rendering during drag
Issue 2: Gizmo responded to all mouse buttons and retained cached hit data that interfered with camera operations

Changes

src/DynamoManipulation/NodeManipulator.cs - Mouse button filtering, pan/orbit detection, ClearHitState call, forceAsyncCall fix
src/DynamoManipulation/TranslationGizmo.cs - Added ClearHitState() method
test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs - Comprehensive test coverage (8 tests, all passing)

Performance

Preserves PR #12614's performance optimization - graph updates occur only on MouseUp, not during drag.

Testing

All 8 new unit tests passed in Visual Studio Test Explorer.

Fixes two issues with gizmo manipulation: 1. Gizmo redraw failure during drag - fixed by adding forceAsyncCall=true to render queue 2. Camera drift when zoomed in - fixed by filtering mouse events and clearing stale hit state Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>

github-actions

See the ticket for this pull request: https://jira.autodesk.com/browse/DYN-6738

Copilot

Pull request overview

This PR fixes two critical issues with gizmo manipulation in Dynamo: redraw failures during drag operations and camera drift when zoomed in close. The fixes ensure proper async rendering during manipulation and prevent mouse event conflicts between gizmo manipulation and camera operations.

Changes:

Added mouse button filtering to restrict gizmo manipulation to left-button-only events
Implemented ClearHitState() method to clear cached hit data after manipulation
Fixed async rendering during drag by adding forceAsyncCall=true parameter

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File	Description
`src/DynamoManipulation/NodeManipulator.cs`	Added mouse button filtering, pan/orbit detection guards, ClearHitState invocation, and forceAsyncCall parameter fix
`src/DynamoManipulation/TranslationGizmo.cs`	Implemented ClearHitState() method to clear hitAxis and hitPlane fields
`test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs`	Added comprehensive test suite with 8 tests covering button filtering, pan/orbit detection, and hit state clearing

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs

src/DynamoManipulation/TranslationGizmo.cs

src/DynamoManipulation/NodeManipulator.cs

aparajit-pratap · 2026-01-26T02:55:53Z

src/DynamoManipulation/NodeManipulator.cs

            // Doing this triggers a graph update on scheduler thread
            OnGizmoMoved(GizmoInAction, offset);

            // redraw manipulator at new position synchronously


Do we need to update this comment? The fact that it was specifically mentioned synchronously before, I wonder if the behavior should be changed to async in the first place.

What bug does this address exactly?

The comment was not updated when the change was made, but it should have

Changing from synchronous to async was an effort to make sure the gizmo does not stutter when dragging it. In my testing there was a minor lag when dragging. The change did make it more responsive, but did not completely eliminate the lag.

Since it is just a minor improvement, should I revert the change? Or leave it and update the comment? What do you think?

So, do you agree then that the comment should be updated to "asynchronously"?

Yes. Either change the comment or revert this change to calling AddGeometryForRenderPackages. Like I said, it was a marginal improvement and might be unnecessary. Based on the comment, it seems pretty intentional that it was supposed to be synchronous. I'm good reverting the change.

I'm not sure about deciding between synchronous vs async, or how to assess that. If you feel that the dragging is smoother with the latter, then let's keep the change.

aparajit-pratap · 2026-01-26T02:58:20Z

@jasonstratton, you mention in the description - Gizmo redraw failure during drag. Is there a failure during drag? What exactly is this failure? Is it pointed out in the ticket, or is this a separate bug that you fixed in this PR itself?

Secondly you mention Camera drift when zoomed in close. I could only reproduce the gizmo drift with panning and orbiting of the camera. What do you mean by zoomed in close? Does that also cause the drift?

jasonstratton · 2026-01-26T20:33:25Z

@jasonstratton, you mention in the description - Gizmo redraw failure during drag. Is there a failure during drag? What exactly is this failure? Is it pointed out in the ticket, or is this a separate bug that you fixed in this PR itself?

There were 2 issues mentioned in the Jira issue.

The gizmo will drift when panning/orbiting
The gizmo does not update when being dragged

So the question about the "Gizmo redraw failure during drag" refers to the latter. When clicking on one of the arrows in the gizmo and dragging, the gizmo remains stationary until MouseUp. So the PR will redraw the Gizmo when dragging it so that it follows the cursor motion.

If I understand the PR you located, it was an optimization so that the geometry associated with the selected node does not move. I imagine there was a performance issue when updating the geometry, but the regression after that change was that the Gizmo did not update. Does that sound correct to you?

Secondly you mention Camera drift when zoomed in close. I could only reproduce the gizmo drift with panning and orbiting of the camera. What do you mean by zoomed in close? Does that also cause the drift?

I while fixing the bug I got into a state where the Gizmo drift did not happen, but when I zoomed in and then panned/orbited, the gizmo drift did happen. ... This may have been an issue with my testing, but it did happen multiple times. I then zoomed out and the drift would continue. But if I tried translating the gizmo again and then pan\orbit again, the drift would not occur again until I zoomed in again. I do not recall which line change corrected this behavior.

aparajit-pratap · 2026-01-26T22:45:19Z

@jasonstratton, you mention in the description - Gizmo redraw failure during drag. Is there a failure during drag? What exactly is this failure? Is it pointed out in the ticket, or is this a separate bug that you fixed in this PR itself?

There were 2 issues mentioned in the Jira issue.

The gizmo will drift when panning/orbiting

The gizmo does not update when being dragged

So the question about the "Gizmo redraw failure during drag" refers to the latter. When clicking on one of the arrows in the gizmo and dragging, the gizmo remains stationary until MouseUp. So the PR will redraw the Gizmo when dragging it so that it follows the cursor motion.

If I understand the PR you located, it was an optimization so that the geometry associated with the selected node does not move. I imagine there was a performance issue when updating the geometry, but the regression after that change was that the Gizmo did not update. Does that sound correct to you?

Secondly you mention Camera drift when zoomed in close. I could only reproduce the gizmo drift with panning and orbiting of the camera. What do you mean by zoomed in close? Does that also cause the drift?

I while fixing the bug I got into a state where the Gizmo drift did not happen, but when I zoomed in and then panned/orbited, the gizmo drift did happen. ... This may have been an issue with my testing, but it did happen multiple times. I then zoomed out and the drift would continue. But if I tried translating the gizmo again and then pan\orbit again, the drift would not occur again until I zoomed in again. I do not recall which line change corrected this behavior.

@jasonstratton, the code changes seem fine to me. However, your observations above are confusing and not what I've experienced. Maybe, we could discuss this online tomorrow?

The PR I located was indeed an optimization so that the geometry associated with the selected node does not move until mouse-up. This may not be that big a deal, but if you have heavy downstream logic that depends on that point position updating, the graph will reexecute that many times for each point position update, which could be repeated performance-heavy computation of largely disposable intermediate results.

The regression after that change was that the Gizmo drifted on panning and orbiting - at least that is what I observed. I also have an explanation for it: the PR introduced changes to the mouse-up handler that executed even after a camera change (pan/orbit) event, which was unnecessary and caused the gizmo to jump.

aparajit-pratap · 2026-01-26T23:28:35Z

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs

+
+        /// <summary>
+        /// Verifies that ClearHitState method exists and properly clears hitAxis and hitPlane fields.
+        /// This is the core fix for Issue 2 (camera drift prevention).


This comment is misleading. ClearHitState is just a guardrail, not the main fix.

Agreed. I will update.

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs

aparajit-pratap · 2026-01-26T23:36:14Z

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs

+            {
+                // Act - MouseUp should not throw and should be ignored in orbit mode
+                var leftButtonArgs = CreateMouseButtonEventArgs(MouseButton.Left);
+                Assert.DoesNotThrow(() => mouseUpMethod.Invoke(manipulator, new object[] { null, leftButtonArgs }),


How does not throwing from the method verify that mouseUp is ignored?

If panning or orbiting, the MouseUp event should simply return
https://github.com/DynamoDS/Dynamo/pull/16852/changes#diff-0195a9bd38735814af7fb83cb7845540c0de8391a1dae99901a56a9adf06b871R250

Yes, but if it doesn't return, that doesn't mean that it will throw.

aparajit-pratap

Minor comments and questions, then LGTM.

Copilot AI review requested due to automatic review settings January 23, 2026 21:53

github-actions bot reviewed Jan 23, 2026

View reviewed changes

Copilot AI reviewed Jan 23, 2026

View reviewed changes

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs Outdated Show resolved Hide resolved

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs Show resolved Hide resolved

src/DynamoManipulation/TranslationGizmo.cs Show resolved Hide resolved

aparajit-pratap reviewed Jan 26, 2026

View reviewed changes

src/DynamoManipulation/NodeManipulator.cs Show resolved Hide resolved

aparajit-pratap reviewed Jan 26, 2026

View reviewed changes

test/DynamoCoreWpf2Tests/ViewExtensions/GizmoManipulationTests.cs Outdated Show resolved Hide resolved

aparajit-pratap reviewed Jan 26, 2026

View reviewed changes

aparajit-pratap approved these changes Jan 26, 2026

View reviewed changes

Addressed PR comments

c775a8e

jasonstratton merged commit f824108 into DynamoDS:master Jan 27, 2026
26 of 27 checks passed

DYN-6738: Fix gizmo redraw and camera drift issues #16852

DYN-6738: Fix gizmo redraw and camera drift issues #16852

Conversation

jasonstratton commented Jan 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Root Causes

Changes

Performance

Testing

Uh oh!

github-actions bot left a comment

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

aparajit-pratap Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aparajit-pratap Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aparajit-pratap commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

jasonstratton commented Jan 26, 2026

Uh oh!

aparajit-pratap commented Jan 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

aparajit-pratap left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

jasonstratton commented Jan 23, 2026 •

edited

Loading

aparajit-pratap Jan 26, 2026 •

edited

Loading

aparajit-pratap Jan 26, 2026 •

edited

Loading

aparajit-pratap commented Jan 26, 2026 •

edited

Loading

aparajit-pratap commented Jan 26, 2026 •

edited

Loading