5A794w has been OK for me thus far on two different Mac models with 10.10.3 and 10.9.5.
However, monetarily I thought I saw a “flicker”. I was in a ghosted left view of the cplane, thinking I had properly created a cplane in that left view. Attempted, erroneously, to move an object in this state and the ghosted object failed to move (as it should I suppose) but it “flickered” too. Don’t know if that is to be expected.
Once I created a proper cplane, all was well again. Not sure if this is relevant???
Meant to imply that pre-release OSs are asking for trouble on a production machine, unless you are just into that for the fun of it (nothing wrong with that), or have a separate dev partition to play with.
I will check tomorrow, to see what my other machine is running. This was happening last week, before the 10.10.4 update this morning, with latest 5A794w build. I have different machine and hardware here …
Rhinoceros version: 5.0 WIP (5A794w)
IronPython version: 5.1.2015.131
Language: en (MacOS default)
OS X version: Version 10.10.4 (Build 14E11f)
I no longer think this is related to the OS X version. The computers with this issue have several large displays and relatively small GPU memory sizes.
Mac Rhino recently switched to a faster drawing method that requires more GPU memory, so the computers with small GPU memory are likely running out of GPU memory. This problem is more likely to appear when opening multiple Rhino models.
The previous drawing method used less GPU memory, but would also infrequently crash on some computers.
Computers with 512MB of GPU memory and more than one display will revert to the old drawing method. This change is in the 5A808w WIP release.
Good deal. Hoping this cures the issue. I take a 15% performance hit rendering wise using the 970’s for video, so where possible I like to stick to the lowly GT120 when rendering (which is pretty much 24/7). By not using the GPU’s for video I not only don’t have the performance hit when rendering, the UI remains a lot more responsive, and I don’t really even notice the renders as there’s very little CPU hit when rendering via the GPU’s on the 970’s.
The 5A808w WIP reverts to the previous drawing technique in pretty specific circumstances. You can force the regression with a test command. Run TestUseBackBuffer and change the mode to Use D I B. This setting does not persist between sessions, so you need to run this test command each time you start Rhino.
Rhino likes to use a lot of GPU memory, but it also has to share with the OS and all the other applications that are running. The Rhino antialiasing setting and the number of open Rhino windows will also affect how much GPU memory Rhino needs.
Not sure why, had this problem, restarted Rhino, it was gone.
For me it was that I couldn’t work in the standard bottom-right viewport. Set to ‘Right’. As I clicked in there, it turned white, so I couldn’t work. When selecting another viewport, the display would reappear.
Yup, it’s still there. Encountered it last night. To verify restarted with the one of the 4GB GTX 970’s and after an hour or so the dreaded whiteout popped up again. Seems to happen more frequently when I have opened more than one Rhino file.
Question: Normally I use only my GT120 while modeling as blender is generally rendering on the 2 GTX970’s. You mentioned that Rhino likes to use GPU memory for openGL. Does it do this on the in use video card, or any available? I.E., is it attempting to use the 970’s for open GL or just the GT120 that the displays are attached to? If so, that might be a cause for whiteouts when the 970’s are rendering cycles frames in blender. A little clarification there may help in figuring out the cause.