Issues with display modes in Rhino BETA

OBS can use that as well. Nvidia experience inserts overlay crap, OBS does not.

Rhino 7 works flawlessly since years, so it’s worrying that Rhino 9 fails in the same conditions and is dependent on industry standard programs such like Nvidia Experience.

I also no longer start my screenshot program (Gadwin Printscreen) with Windows 10, in order to minimize the risk of bugs. Both Rhino 8 and Rhino 9 cause an old bug that triggers the opening of the radial pop-up menu of Gadwin Printscreen. Rhino 7 never does that! I warned the Rhino developers about that bug since the Rhino WIP times a few years ago, but there is still no solution about found. Rhino 8 has so many bugs initially that I understand why the developers were too busy at the time to look at this particular bug. However, it’s obvious that something in the code of Rhino 8 has changed to worse compared to Rhino 7, because the same bug was also translated to Rhino 9 WIP and Beta.

Also, note that the custom display modes of Rhino 9 need 1-2 seconds to load their respective environment map, whereas the loading is instant in Rhino 7. Sometimes the environment map of the custom display modes will not load unless I move/pan/rotate the videwport by the mouse or my 3d mouse. Looks like program will not redraw the viewport after switching to a different display mode, so I’m forced to do that manually. I showed that behaviour in multiple videos in other threads with bug reports. Other users also had the same issue, so its not an isolated case.

I started to use the stock Rhino 9 Beta in the last days, made a clean install with manually deleted folders. I even stopped to use my 3d mouse and Gadwin Printsreen, stopped Nvidia Experience and any other program, but the bugs mentioned above still persist.

None of these problems sound like they have anything to do with the display pipeline or display modes… and everything to do with some of the internal changes that have been made elsewhere in the UI and file management.

The “delayed loading” is something that I think @andy needs to address and look at, because texture file loading has been turned into a background process that sounds like it’s failing to update the views when it’s done in some cases…it also will cause a slight delay if/when there are lots of textures or very large files.

The other issue(s) sound more like mouse and keyboard handling rather than graphics hardware or display pipeline.

Sorry if this has already been asked and provided, but can you post a video of this “pop up” issue, and explain what you do to get it to happen?

Thanks,

-Jeff

Sure, I will send you a short video with the Rhino 9 Beta startup in a few minutes. Check your PM soon.

Note that the pop-up radial menu of Gadwin Prinsscreen is also triggered by various actions in Rhino after the startup, such like opening some toolbars, clicking on some icons, during certain commands etc. This applies to both, Rhino 8 and Rhino 9 WIP/Beta.

I also use f.lux to reduce the eyestrain. However, when it’s turned off, all the bugs in Rhino 9 Beta remain there, meaning that they are caused by something wrong with the code of Rhino 8/9. As mentioned before, Rhino 7 is extremely stable and does not exhibit any of the bugs even with a heavy customization, plug-ins and many other programs running simultaneously.

By the way, the latest Rhino 9 Beta needed 58 minutes to install! The version prior that (released several days ago) needed 29 minutes for the installation, if I remember correctly. I already wrote that in some topic these days. Half or one hour is a huge amount of time to just install a program. Last month, the installation process of Rhino 9 WIP was way faster than that.

Here is another example where Rhino 9 Beta evoked the pop-up radial menu of Gadween Printscreen.