Force arrows sputter when dragging block

[Nancy-Salpepi]

Test device
iPad 9th generation and MacBook Air

Operating System
iPadOS 17.6.1

Browser
Safari

Problem description
For phetsims/qa#1136, in Buoyancy and Buoyancy basics on the Compare Screen:
Dragging Block 2A at max volume along the bottom of the pool causes the force arrows to sputter. It also happens with Block 1B at max mass.

Steps to reproduce

1. On the Compare Screen select Same Volume
2. Move Volume slider to 10
3. Check the 3 forces checkboxes
4. With touch or mouse grab Block 2A and move it along the bottom of the pool
5. With alt input, tab to Block 2A at the bottom of the pool, grab it and press the down arrow key once. The arrows will sputter continuously even though you aren't moving the block at all.

Visuals

Arrows.mp4

arrowsAltInput.mp4

[KatieWoe]

I think this is related to something I've noticed that isn't necessarily a bug. If the contact vector is zero, but you are dragging, or if you let go and the contact vector becomes zero, there will still be space made for it, and it will take a second or two to disappear. The vector looks like it is switching between making room for a positive then a negative contact vector?

[zepumph]

Maybe we just need a tolerance, so that if the contanct force is 1E10 we still don't show the arrow.

[samreid]

The threshold is already set to 1E-5. I raised it until the flickering went away, and by then it was up to 0.2:

Subject: [PATCH] Convert to *.ts, see https://github.com/phetsims/density-buoyancy-common/issues/377
---
Index: js/common/view/ForceDiagramNode.ts
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/js/common/view/ForceDiagramNode.ts b/js/common/view/ForceDiagramNode.ts
--- a/js/common/view/ForceDiagramNode.ts	(revision 576404eb2e408acd95c8eeb3fb3ff6a7dd8155e5)
+++ b/js/common/view/ForceDiagramNode.ts	(date 1725067808303)
@@ -125,7 +125,8 @@
 
     const updateArrow = ( forceProperty: InterpolatedProperty<Vector2> | BlendedVector2Property, showForceProperty: TReadOnlyProperty<boolean>, arrowNode: ArrowNode, textNode: Text, labelNode: Node ) => {
       const y = forceProperty.value.y;
-      if ( showForceProperty.value && Math.abs( y ) > 1e-5 ) {
+      if ( showForceProperty.value && Math.abs( y ) > 0.2 ) {
+        console.log(y);
         arrowNode.setTip( 0, -y * this.displayProperties.vectorZoomProperty.value * 20 ); // Default zoom is 20 units per Newton
         ( y > 0 ? upwardArrows : downwardArrows ).push( arrowNode );
 

That works well along the bottom but dragging the block to the bottom left corner still flickers. But if we make the threshold too high, then the numbers won't add up. Like if the forces were a = +4.9, b = +0.1, c = -5.0, then they would show as a=+4.9, b=0, c=-5.0. I feel we don't have much wiggle room with the p2 engine though. But I see the contactForce is blended but the other ones are not. Maybe look into blending those? Or maybe a combination of blending and a threshold like 1E-2?

[samreid]

I committed a change that blends the gravity and buoyant forces in the same way that the contact force is blended. This smoothed them out enough that we could adjust the threshold from 1E-5 to 0.05 and things are looking better in the cases I tested. I'm still concerned that when we show 2 decimal places (for values <10) that things may not add up, since forces < 0.05N are hidden. You can also still get flickering if dragging a block in the corner.

So I have a lot of hesitation about the commit and think it would be appropriate to test it carefully. @Nancy-Salpepi @DianaTavares or @zepumph could test it independently or it may be just as good or better to discuss and test together during a coming standup.

[Nancy-Salpepi]

It looks much better on main as far as the flickering goes.

I'm still concerned that when we show 2 decimal places (for values <10) that things may not add up, since forces < 0.05N are hidden.

On main, it is possible for the forces not to add up, but I also see that in the dev version. In this screenshot the forces for both blocks don't add up (Block B is being held down):

[DianaTavares]

I love the behavior of the arrows!

It is true that in some cases the values don't add up exactly, But that is something that I can add to the teacher tips, that the sim is rounding to just have one decimal, and that can generate that for one decimal the add of the forces is not complete zero.

But I notice that the numbers stay like that for a small time, and soon go back to the correct values:

For me this issue is solved!

[samreid]

Sounds good, thanks @Nancy-Salpepi and @DianaTavares. Closing.