Hi @DavidEranen.
It seems to have the same behaviour.
Thanks.
Is there also a slowdown if the model is just a simple box or sphere? How large is the model you are testing with?
-David
Just been doing a bit of a test using Task Manager to observe the resource use of CPU & GPU.
Some observations:
-
Rhino 6 seems to clock up almost 100% of the Quadro when spinning the model versus around 60% in v5 for the same model.
-
Itâs independent of model size. Even smaller models can be an issue.
-
Iâve just tested a small model and for some reason itâs even slower than the large model Iâm working onâŚ
If you maximize the perspective viewport and switch to Wireframe or Shaded mode. Is it slow still when you move to other monitor? How about Rendered mode. Slow on other monitor?
If itâs only slow in Rendered mode, try disabling Skylight.
-David
@DavidEranen Itâs seems to have erratic behaviour. The SL doesnât seem to affect it. Iâve just toggled between maximized perspective viewport and 4 view and back again and it appears to have slowed down another 50%!!!
Unpredictable⌠Almost like it slows down the longer I work on the fileâŚ
Another observation. The bigger the viewport, the slower the model⌠I can have a small perspective viewport, and even zooming in close to more complex models is quick. The larger I make the view, the slower it getsâŚ
@sach When you have time, could you time the following things:
All tests in fullscreen viewport, rendered mode without skylight shadows, and a simple test model:
Timing of TestMaxSpeed on:
- 4k screen in 4k resolution.
- 1200p screen while 4k screen is in 4k resolution.
- 4k screen in 1080p resolution.
- 1200p screen while 4k screen is in 1080p resolution.
Remember to log out and back in after changing the resolution of the 4k display.
Thanks
-David
Letâs just wait to see what else we can determine for now⌠It there is a problem in V6, and it can be fixed or tuned up, then we donât want to lose the configuration that shows the problem.
David looks like heâs on the hunt for this one, so letâs just see what he comes up with.
-Jeff
For what itâs worth, I have run into some graphics issues, (in other applications, none in RhinoâŚyet), that were related to Dellâs âSwitchable Graphicsâ setting, also referred to as âOptimusâ. (pretty sure thatâs what itâs calledâŚedit: I think Optimus is an NVidia term).
Itâs intention is for machines with 2 video cards, and it will âintelligentlyâ switch depending on what the application needs. This is on machines with onboard intel cards, and a second âhigher performanceâ card. It might be worth trying to disable âSwitchable Graphicsâ in the bios and see what you get.
It seems that graphics issues, on dell laptops, with multiple cards, with external/second monitors connected via display portsâŚcan sometimes get a little unruly. Maybe this is worth a read?
Here are the results. The model is 100* 100mm2 (Polysurface) boxes.
-
4k screen in 4k resolution.
2.61s
38.33 FPS
Maximized perspective VP at 3192*1469 -
1200p screen while 4k screen is in 4k resolution.
5.19s
19.28 FPS
Maximized perspective VP at 4152*2309 -
4k screen in 1080p resolution.
1.67s
59.81 FPS
Maximized perspective VP at 1500*715 -
1200p screen while 4k screen is in 1080p resolution.
1.67s
59.81
Maximized perspective VP at 1980*1135
Thanks!
Sach
Hi @sach,
Interesting.
First point: It looks like the resolution rendered on the 1200p is 4x more pixels than it should be rendering. The display canât even show that many pixels. This is probably due to the 4k monitor being the main display and the DPI is ~2x higher than the 1200p display.
Second point: It looks like V-Sync is enabled for Rhino. Can you go to NVIDIA settings and force-disable V-Sync for the Rhino application? Does this change anything? Iâm thinking it might be interfering.
-David
Hi @sach,
Sorry, no progress. We have made a YouTrack item so we will eventually get to it, but I canât say when.
@stevebaer and @jeff, I would appreciate if you could read through this thread (re-read for @jeff) and comment on what you think might be wrong or what we could test to find the root cause of the problem. Any suggestions are appreciated.
-David
I have seen that DPI mix-up here as wellâŚItâs when you change the DPI scaling in Windows but donât logout and back in (or reboot)⌠Windows just applies the scale factor across the board to whatever factor currently exists⌠I got my iMac (running Windows) using 10000x8000 at one point⌠Tearing off the viewport for a floating view crashed Rhino due the amount video memory it was trying to useâŚ
If youâre getting resolutions reported that are greater than what your physical monitor is capable of, then you have a configuration error somewhere⌠I would start by setting Windowsâ DPI setting to 100%âŚnothing more, nothing less⌠Logout and reboot⌠Then see what Rhino says your viewport resolution is.
-J
Weâre getting somewhere! Setting the scaling to 100% (down from the recommended 250%) makes Rhino respond as expected on the 2nd monitor.
Comparing the Rhino maximized VP, the approx. resolution:
4k main display, ~3500 px
1080 2nd display in âExtendâ mode, ~ 1600 px
But, now everything is tiny and illegible on the primary display!! Can you suggest how to address this?
Thanks,
Sach
Iâm not sure⌠The problem I reported above happens if you donât reboot after changing the DPI setting⌠In other words, if you just go into Windowsâ settings and change the DPI, close the settings dialog and just keep working⌠In fact, I think Windows even warns you with something like âSome applications will not work properly until you logout or rebootâ (donât remember the exact wording)âŚ
So that being said⌠What happens if you set the DPI back to 250%, logout, rebootâŚand then try?
The thing to watch out for is what resolution is being reported in Rhinoâs viewport tabâŚsee pic.
If your view is maximized, and the Width and Height values seem (or are) larger than your physical screen capabilities, then something is wrong somewhere with the DPI settings. Rhino should never be using a resolution that is larger than what is possibleâŚand the reason it even works is because when Rhino goes to move the frame buffer contents to the glass, the internal mechanism it uses to do so is scaling the results down to fit the âactualâ viewport sizeâŚwhich may also be contributing to the slowdown.
- Determine what the maximum screen resolution is for your current config. Note: This is not necessarily the maximum resolution that your monitor is capable of⌠especially if youâre changing the DPI scale⌠It is the resolution you select in Windowsâ Display settingsâŚsee pic.
So in the case above it would be 1920 x 1080âŚ
- Now maximize Rhino, and then maxmize a viewport⌠and look to see what Rhinoâs viewport tab reports as the Width and Height of the view⌠it should be close to (in this case) 1920x1080⌠itâs not going to be exact due to things like the command line, toolbars, and status bar all taking up screen real estate, but it should be close⌠What it should NOT be is something like 2x to 3x the size. If it is, then something is wrong.
So given all of that⌠I would first make sure that what youâre seeing from Rhino is all making sense in terms of resolutions and viewport sizes⌠Once youâre sure those are all correct, then I would start looking at performance⌠But until you can figure out why the correct resolutions arenât being used (either a bug in Rhino or a Windows config problem), looking at performance issues will just result in false negatives (IMO).
-Jeff
Hi @jeff
Thanks for the update.
Iâve changed the main display back to 250% (the windows recommended setting), logged out and back in and weâre back to square one! So, the resolutions are: