I have been finding that viewports in V6 become unresponsive after sitting idle for a while (may be related to Windows Settings -> Power and Sleep -> When plugged in, turn (screen) off after), I first noticed in the last wip, but it has continued into the most current. As far as I can tell, Rhino itself is fine, I see the command line behaving, the cursor shows appropriately (what would be a pan or tumble shows the correct hand or orbit cursor, cross hairs when asked to pick a point), but viewports don’t redraw. 4view will fix it.
So, over here this is repeatable in this file and display mode. On my workstation, I have it set to turn off screens (I set it at 3 minutes so I could test faster), sleep is set to never. Under Lock the computer when I leave it alone for a period of time -> Screen saver settings, screen saver is blank, and it is set to wait 3 minutes on resume display logon screen.
This file should open in a 4view type setup, and the Perspective view is set to the attached display mode (called Rendered Gradient), the other three viewports are the pre-canned wireframe.
I have my Surface set similarly to SamPage’s, but I can not duplicate the problem.
The screen goes dark after it’s time interval.
When I bump it and unlock the screensaver, I’m back in the file as if I never left.
I’m no help for this problem.
I know this is kind of dead in the water because it can’t be replicated on your end, but to add a bit more info (and to ask a question), this also effects layouts. However with layouts, the 4view trick doesn’t work as it only rebuilds model space viewports. Is there anyway to “reset” a layout? Currently I have to close and reopen Rhino; the only other thing I could think of was to Ctrl + A Ctrl + C everything on the affected layout, closeViewport, call Layout to recreate the sheet, then Ctrl + V everything back. Closing and reopening seems preferable to this though.
When you get to the download page for the WIP (from a link in the “Welcome” post that is pinned at the top of the Serengeti category) you will find a link to what’s new.
Jeff and I added a couple test commands to the latest WIP to try and help us figure out what is happening on your computers when Rhino display “locks up”. Hopefully this will point us in the right direction to where the bug actually exists.
TestPaintReport
This command just prints the message “Draw message X” to the command line where X is an ever increasing number. If you run this command and pan in your viewport, you can see what I’m describing. When Rhino freezes up, try running this command. This command is testing to make sure Windows paint messages are appropriately getting processed. Does the command line continue to print new messages as you try to do something like pan in a “frozen” viewport?
TestGLValidateFBO
There are cases where OpenGL frame buffer objects (FBOs) can become invalid. When the viewports become frozen, please run this command. This command prints the state of the active FBO to the command line. Please send us the command line report.
Thanks guys, and hopefully these commands will lead us to the actual bug. At a minimum they’ll help us eliminate some of the guesses we have at what is happening.
Yes, as I pan about in an unresponsive viewport, I see Draw message xxx on the command line.
Active view’s FBO is valid
Data buffer output[0] - color attachment 0
Attachment Type: Texture
Attachment object name: 5
–EDIT–
After running 4view to refresh viewport so they work again, TestGLValidateFBO reports:
Active view’s FBO is valid
Data buffer output[0] - color attachment 0
Attachment Type: Texture
Attachment object name: 1
In paper space (which is still frozen regardless of 4view):
Active view’s FBO is valid
Data buffer output[0] - color attachment 0
Attachment Type: Texture
Attachment object name: 16
Thanks Sam, at least we know we’re barking up the wrong tree now. Back to the drawing board to see if we can come up with other ideas of where things are going bad
So playing with this some more, a few other random tidbits. It seems to be just the screen saver settings, not related to Power & sleep screen setting. If I have screen saver set to (None) and “On resume, display logon screen” is true, I see the frozen viewport. If screen saver is set to Blank and “On resume, display logon screen” is false, I see it as well (screen saver None and display logon screen = false doesn’t do anything)
When frozen, if I change display modes, the viewport will redraw correctly, but as soon as I try to do anything (pan, draw a line), the viewport snaps back what it was frozen on when resuming from screen saver, and is unresponsive.
If I do the change display mode trick, and do something so the viewport goes back to the frozen state, when I quit Rhino, the viewport flips back to what it showed on the last display mode change draw. Upon hitting cancel, it snaps back to the frozen after screen saver.
Rhino has to be the active document when the screen saver kicks on. If it isn’t, the freezing isn’t as reliable.
Only other odd thing about my setup I can think of is I have stuff (Properties, Layers, Materials, etc.) on a second screen. Thinking it might be that, I tried TestHideOnDeactivate but no difference.
I have now tested with the screensaver settings as Sam did.
I also had the screen saver set at blank and now I changed it to none. The energy saving is set to turn off screen after 15 min.
Now when I have the screen saver set to none I don’t get any lockup’s (yet). “On resume, display logon screen” is set to false.