So Sam, does that mean if Rhino is not the active application and/or the foreground window when your monitor turns off, then the viewports will not be frozen when jiggling the mouse and then selecting the Rhino app?
-J
So Sam, does that mean if Rhino is not the active application and/or the foreground window when your monitor turns off, then the viewports will not be frozen when jiggling the mouse and then selecting the Rhino app?
-J
It appears so, yes. So if I have Rhino open, then open Chrome making sure Chrome is active, then let it sit until screen saver turns off the screens, when I jiggle the mouse to wake then make Rhino active again, all viewports and layouts work.
Sam
Ok thanksā¦very odd.
Iāve tested this too. I agree with Sam, everything is normal if Rhino isnāt the active program when the screen saver kicks in. Iāve tested with several other programs and it is only when Rhino is active, it locks up.
Hi everyone,
There will be yet another new Test command in the coming (daily) WIPā¦ It basically has the ability to track specific power events, which provides me a way of detecting a specific event, and then present you (the user) a series of options on which you can then act.
So the current idea is this:
Note: The options are in order of severity (from left to right), where the leftmost option is the least destructive and the far right one being the most destructiveā¦
To enable this, run:
TestTrackPowerStates
and āEnableā power tracking for āMonitorPowerāā¦ currently itās the only one there, but I foresee others coming online (if none of this works).
So basically ā-_TestTrackPowerStates MonitorPower=Enable enterā
ā¦the command line should then display āPower State Tracking for the Monitor is now ONā¦ā
Then wait for the screen or system to shut off.
Wake the system back up.
You should then see a dialog popped up in the center of Rhinoās screen telling you that a power event has been detected and to follow the command line options.
The only purpose of this dialog is for sanity, letting you/me know that the event tracking is working correctly.
Just click the āOKā button to close it, and follow the instructions I outlined above in #2.
If any of the options work, then please also try them for Layoutsā¦as they might not work for them, or may require a different option or set of options.
Lastly, itās possible that one or more option is requiredā¦so devise your own way for keeping track of which options were/are needed to clear up the frozen view(s)ā¦but be aware, once the views are no longer frozen, it might be due to only the last option you selected and not because of any of the other optionsā¦and vice versaā¦which is why #2.c.ii above is an important step.
If for some reason you do not get that initial dialog popping up when you wake your system, then obviously none of this is going to work and itās back to the drawing board for you (and possibly others)ā¦but Iāve tested this on several systems here, and the tracking does seem to be working consistently.
Thanks,
-J
Iām only on the public weeklies, will the test command be in that, or do I need to get something else to try it out?
Sam
Nothing special you have to doā¦It will be in the next WIPā¦but unfortunately this weekās WIP has been delayed due to an outstanding stop-ship bugā¦so youāll have to wait until it goes out or possibly next Tuesday.
@jeff I had the same problem after closing the options window, Rhino would only redraw where the window was. But It does not happen always. I will test again with the latest beta in about 2 weeksā¦ (traveling now)
@Goswin Ok, this sounds like a really old problemā¦ What OS are you using?
Please try this using V5ā¦(Iām assuming you donāt see this problem in V5)
Start V5
Go into Options->View->OpenGL
UNCHECK the option "Redraw scene when viewports are exposed"
Close the Options dialog.
Now see if you can get the same problem to happen using V5ā¦ It might not happen using the same scenarios youāre using in V6, but theoretically, it should happen at some point.
Let me knowā¦
Thanks,
-J
RH-40627 is fixed in the latest WIP
OK, so I only get the dialog when both Screen Saver is on AND turn off the display is on. This may not be surprising, as the command is looking for power state change, but I can get the freeze and no dialog when it is just screen saver and turn off the display is false.
With Screen Saver and turn of the display on I get:
Model space:
Layout with no active detail (The following is true if starting in model, fixing model with ReplaceViews, then switching to still frozen layout, of if letting monitor turn off while in layout )
In Layout with detail active:
Let me know if I missed anything,
Sam
Thanks @SamPage, I need to go over this and see if I can now find a possible causeā¦ But unfortunately, it still sounds like nothing fixes the layouts with detailsā¦ So I may come up with another option to choose from (not sure what that would be atm).
I would also be curious if any of the other options also fix model space.
Thanks again,
-J
I have tested in model space only.
RestoreViews: nothing happens, still locked
ReplaceViews: Everything works OK again
RecreatePipelines: Everything works OK again
ResetOpenGLRecources: nothing happens, still locked
RecreateAllHandles: Everything works OK again
I have done this scheme both forward and backwards and I have also done it without restarting the test and the result is the same every time. I have also tested with waiting for the sleep to occur and with only the screen saver going in and the result is the same.
Hi @Goswin, A change has been made in the latest WIP that attempts fix the āregionā bugā¦I know youāre out, but Iām just typing this now so I donāt forget.
Note: This is not in regards to the frozen viewports discussed in this threadā¦this is about the video you posted where areas of the viewport are clipped. Also, please let me know if you managed to reproduce this problem in V5 per my instructions earlier.
Thanks,
-J
Hi @permalare,
Great! This is good news to meā¦ The next weekly WIP will have more options (specifically to address Layouts), but it sounds like RecreatePipeline and RecreateAllHandles seems to be getting things unstuck, so Iām going to concentrate on what it is theyāre doing to see if I can come up with a more targeted fix.
Thanks again for all the feedback and of course patience on this one.
-Jeff
@SamPage, Any chance to test āRecreatePipelinesā and āRecreatedAllHandlesā for model space freeze?
Thanks,
-J
Sorry, yes, same results as permalare in model space for RecreatePipelines and RecreateAllHandles. One request for next WIP, could you make a command for this? Sometimes I fix model and exit forgetting to fix layout and it would be nice to not have to wait for screen saver to kick on to get it back. (I think RecreatePipelines fixes it everywhere regardless of what space Iām in, so I can just remember to use that one)
Thanks,
Sam
Any one? ā¦ You mean something like āTestRecreatePipelinesā ?
-J
I had been using RepalceViews in model then switching to Layout and using RecreatePipelines, but it looks like if I just use RecreatePiplelines, it fixes it everywere (except the active detail in layout), so I can just use that, and I donāt think you need to bother with a special command for me.
Sam
@SamPage
Can you elaborate on that one? Are you saying that the active detail (i.e. itās been double-clicked and is in edit mode) is the only thing frozen? Thatās hard to diagnose since an āactiveā detail sucks up all mouse eventsā¦If you deactivate it and then reactivate it, is it back to normal?
-J