Frozen Viewports?


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.

Anyone else seeing this?

(Pascal Golay) #2

Hi Sam - nothing like that here so far - can you copy/paste the output from SystemInfo ?




Rhino 6 SR0 2017-6-21 (Rhino WIP, 6.0.17172.1151, Git hash:master @ ac2391d7625174b8a345613c644dbe31837ce3aa)

Windows 10.0 SR0.0 or greater (Physical RAM: 32Gb)

GeForce GTX 780 Ti/PCIe/SSE2 (OpenGL ver:4.5.0 NVIDIA 376.53)

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On

Anti-alias mode: 8x
Mip Map Filtering: None
Anisotropic Filtering Mode: None

Vendor Name: NVIDIA Corporation
Render version: 4.5
Shading Language: 4.50 NVIDIA
Driver Date: 12-29-2016
Driver Version:
Maximum Texture size: 16384 x 16384
Z-Buffer depth: 24 bits
Maximum Viewport size: 16384 x 16384
Total Video Memory: 3 GB

C:\Program Files\Rhino WIP\Plug-ins\SolidTools.rhp “SolidTools” n/a
C:\Program Files\Rhino WIP\Plug-ins\Commands.rhp “Commands” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk.rhp “Renderer Development Kit” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoScript.rhp “RhinoScript” n/a
C:\Program Files\Rhino WIP\Plug-ins\RPC.rhp “RPC” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoBonusTools.rhp “Rhino Bonus Tools” n/a
C:\Program Files\Rhino WIP\Plug-ins\AnimationTools.rhp “AnimationTools” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoRender.rhp “Rhino Render” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” n/a
C:\Program Files\Rhino WIP\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI” n/a
C:\Program Files\Rhino WIP\Plug-ins\NamedSnapshots.rhp “Snapshots” n/a
C:\Program Files\Rhino WIP\Plug-ins\CyclesForRhino.rhp “Cycles for Rhino” n/a
C:\Program Files\Rhino WIP\Plug-ins\RhinoCycles.rhp “RhinoCycles” n/a
C:\Program Files\Rhino WIP\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” n/a
C:\Program Files\Rhino WIP\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino WIP\Plug-ins\Displacement.rhp “Displacement” n/a
C:\Program Files\Rhino WIP\Plug-ins\Calc.rhp “Calc” n/a

(Pascal Golay) #4

@stevebaer - Hi Steve- dunno if you have an idea about this, maybe?


(Steve Baer) #5

Not a clue; this is the first I’ve heard of this bug. The whole “sleep mode” comments sounds like a possible problem spot.


To be clear, with my power setting it is just turning screens off and locking, not actual sleeping.

(John Brock) #7

I’ll set my Surface to turn the screen off after 25 minutes but not sleep and see if I can make it happen.


The same happens to me.
There is a total unresponsiveness when the screen is lit up after the screen has been asleep.

When I click on 4wiew all screens get blank. I must zoom-all to get the drawings back again.

Well, I found out that the reason the screens go blank is that the drawing is out of the viewports.


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.


Rendered (2.5 KB)
FrozenView.3dm (104.0 KB)

(John Brock) #11

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.


(Wim Dekeyser) #14

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.


same happends to me, Rhino WIP gets unresponsive after a while and I have to shutdown and start over again.

(Steve Baer) #16

@SamPage @Christian2 @permalare @Goswin

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.


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?


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


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


(Steve Baer) #18

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

(Steve Baer) #19

If you run “TestGLWarnings” and restart Rhino, do you ever get a dialog box with an OpenGL error message?


So far no (after a frozen viewport event).

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 get the same messages as Sam does. The only difference’s is the numbers in “Attachment object name:”


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.