Panning while dragging some objects stops working when zoomed in past a certain amount

[KatieWoe]

Test device
Dell
Operating System
Win 11
Browser
Chrome
Problem description
For phetsims/qa#785. I suspect it is related to phetsims/geometric-optics#367.
Seen on Gravity and Orbits. When trying to drag the sun past a certain zoom point, the screen no longer pans with the object. This doesn't seem to happen with the smaller Earth object. However, the sun doesn't seem large enough that I would expect phetsims/geometric-optics#367 to come into play.
Steps to reproduce

1. Go to Gravity and Orbits, 1st screen, Sun-Earth scene
2. Zoom in a bit
3. Drag sun to edge of screen and observe pan
4. Zoom in fully
5. Drag sun to edge of screen
6. While fully zoomed in, drag Earth to edge of screen and observe pan

Visuals

Troubleshooting information:

!!!!! DO NOT EDIT !!!!!
Name: Gravity and Orbits
URL: https://bayes.colorado.edu/dev/phettest/gravity-and-orbits/gravity-and-orbits_en.html?ea&brand=phet
Version: 1.6.0-dev.1 (unbuilt)
Features missing: applicationcache, applicationcache, touch
Flags: pixelRatioScaling
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36
Language: en-US
Window: 1280x649
Pixel Ratio: 1.5/1
WebGL: WebGL 1.0 (OpenGL ES 2.0 Chromium)
GLSL: WebGL GLSL ES 1.0 (OpenGL ES GLSL ES 1.0 Chromium)
Vendor: WebKit (WebKit WebGL)
Vertex: attribs: 16 varying: 30 uniform: 4096
Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32)
Max viewport: 32767x32767
OES_texture_float: true
Dependencies JSON: {}

[KatieWoe]

Noting other instances here:
Data probe in Natural Selections
Molecule in Molecule Polarity
Chemistry book in Friction

[jessegreenberg]

Thanks @KatieWoe. That is right, this is the result of of #1381. One thought I had is we could pan to the center of the object instead disabling pan/zoom when bounds are larger than the screen.

[jessegreenberg]

I tried out #1382 (comment), it feels disorienting out of control.

[jessegreenberg]

In general the behavior for the examples in #1382 (comment) actually feels pretty good to me. It seems like a good compromise for what should happen when dragging something that is currently too large to fit on screen.

The case of gravity-and-orbits is slightly different because the planet has invisible children that are contributing to the Bounds of the Node and making them larger than they should be.

[jessegreenberg]

I don't want to use visibleBounds because I am worried about the performance hit of calling that every move during a drag. (Granted, we are already getting the globalBounds every move).

Would it work to just pan so that we keep a small rectangle around the Pointer in view instead of basing things on the bounds of the drag target?

• Possibly better performance
• Would work for DAG (!!)
• Could still fall back to createPanTargetBounds if we need.
• We don't need to look at the target of the PressListener.
• Does not have the issue of trying to keep things larger than the screen in view.

EDIT: I tried it out and it doesn't work well because the pointer point is always along the edge of the screen, so we just keep panning without mouse moves and leave the draggable behind.

[jessegreenberg]

Over slack @jonathanolson said that using visibleBounds shouldn't be a big performance concern over globalBounds, so I think we can use it here.

[jessegreenberg]

This should be fixed for gravity-and-orbits. @KatieWoe can you please confirm? The other cases in #1382 (comment) will still have this behavior, but it seems they all legitimately have bounds that are larger than the screen. Correct me if I have that wrong.

[KatieWoe]

This looks good in master. If I see issues in other sims I'll let you know, but I think we're ok.

[jessegreenberg]

OK, thanks! Local aqua is doing OK with this change and I am not seeing it on CT (though CT is pretty red atm for another issue and problems may be obscured).

Closing.