Buckle up. This is a wild one. 🐎
Steps to Reproduce
- Be on a Windows 10 machine with at least two monitors
- Open an official release of NetLogo 7.0.1, 7.0.2, or 7.0.3 (32-bit and 64-bit seem equally affected)
- Do not move or resize the NetLogo window from how/where it started
- Run
___camo in the Command Center to open "Bug Hunters Camouflage HubNet"
- Click the "Start" button in the dialog to launch HubNet
- Click the "Local" button in the HubNet Command Center to create a client
- Click the "setup" button
- Activate the "go" button
- Grab the window for the local HubNet client and try dragging it from its starting monitor to your computer's other monitor
What Should Happen
The window moves to the other monitor without anything interesting happening.
What Actually Happens
Screen-tearing:
Notes
For whatever reason, the issue does not occur when building from source. You must test it on a real release.
It is possible to make the screen-tearing go away temporarily, by resizing the window or other actions, but the tearing will sporadically re-appear until NetLogo has been restarted.
While it's most reliable to make this happen with a HubNet client in a running model on a non-maximized window, I've seen it happen with a bunch of other dialogs (most notably, SDM). And I've made it happen a bunch of times with a maximized window, but it's just more random that way. I have found myself unable to make the error occur after shrinking the main window a bunch. So there's some sensitivity to the sizing of the window.
A necessary condition of getting the bug to occur seems to be having the model's go loop running. I chose "Bug Hunters Camouflage" because it's a HubNet model that's very easy model to setup and run. But I've also produced it with other HubNet models, and with SDM models.
Sometimes, the first HubNet client won't want to trigger the issue. I've had success with creating a second HubNet client and seeing the bug then occur on my first try.
While you can move it to a different monitor than its starting one, it has to be back on the starting monitor when you try to make the bug occur. In the Windows "Display" settings, there is a concept of "Main monitor", which is the monitor that new windows will open on. It doesn't matter if Windows is treating the left monitor or the right monitor as the main monitor; as long as NetLogo is on the main monitor and you move the HubNet client to the non-main monitor, the bug should occur instantly.
For testing this, it can be useful to go into the Windows "Multitasking" settings and turn off "Snap windows" (to prevent windows from minimizing while you're dragging things around), but it is not strictly necessary.
I thought the issue might be that my computer had gotten into a bad state, or that my graphics card was dying. Restarting my computer did not fix the issue. Replacing my graphics card and installing new drivers did not fix the issue.
Versions
- 6.4.0: 🟢
- 7.0.0: 🟢
- 7.0.1: 🔴
- 7.0.2: 🔴
- 7.0.3: 🔴
Buckle up. This is a wild one. 🐎
Steps to Reproduce
___camoin the Command Center to open "Bug Hunters Camouflage HubNet"What Should Happen
The window moves to the other monitor without anything interesting happening.
What Actually Happens
Screen-tearing:
Notes
For whatever reason, the issue does not occur when building from source. You must test it on a real release.
It is possible to make the screen-tearing go away temporarily, by resizing the window or other actions, but the tearing will sporadically re-appear until NetLogo has been restarted.
While it's most reliable to make this happen with a HubNet client in a running model on a non-maximized window, I've seen it happen with a bunch of other dialogs (most notably, SDM). And I've made it happen a bunch of times with a maximized window, but it's just more random that way. I have found myself unable to make the error occur after shrinking the main window a bunch. So there's some sensitivity to the sizing of the window.
A necessary condition of getting the bug to occur seems to be having the model's
goloop running. I chose "Bug Hunters Camouflage" because it's a HubNet model that's very easy model to setup and run. But I've also produced it with other HubNet models, and with SDM models.Sometimes, the first HubNet client won't want to trigger the issue. I've had success with creating a second HubNet client and seeing the bug then occur on my first try.
While you can move it to a different monitor than its starting one, it has to be back on the starting monitor when you try to make the bug occur. In the Windows "Display" settings, there is a concept of "Main monitor", which is the monitor that new windows will open on. It doesn't matter if Windows is treating the left monitor or the right monitor as the main monitor; as long as NetLogo is on the main monitor and you move the HubNet client to the non-main monitor, the bug should occur instantly.
For testing this, it can be useful to go into the Windows "Multitasking" settings and turn off "Snap windows" (to prevent windows from minimizing while you're dragging things around), but it is not strictly necessary.
I thought the issue might be that my computer had gotten into a bad state, or that my graphics card was dying. Restarting my computer did not fix the issue. Replacing my graphics card and installing new drivers did not fix the issue.
Versions