I always experience major performance hits when I have more than one viewport visible.
have seen this on quadros too, running a titan X now.
I usually do not need the display in the inactive viewports.
would like to disable these; in fact it helps to pan/rotate the model out of view on the non active viewports, but that is not really a good way to solve the issue.
Hi daniel - so you’re selecting objects in one viewport that sees the 3d model space and selection is affected by the number of details actually visible in a separate layout window, do I have that right?
from my observations, the more viewports the slower everything gets.
in a large model drag more complex geometry, like a large mesh or group of polysurfaces.
in a single full screen viewport smooth like silk.
add a second viewport, slower, also the selection highlight;
add athrid even slower, etc.
so this is not related to only layouts, but in a more complex layout one might have 6-7 detail views. more that in a typical modelling session, and that makes it even more slow.
OK, thanks - I think I am beginning to get the picture - it’s not the panning and zooming itself that is slow, it’s updating after an edit operation. I’d think not updating inactive views might lead to some pretty confusing pictures on screen, hopefully we can address this by improving the display speed instead.
I agree speeding up the display should be the main concern, but for me, the ability to turn off redraw in detail views would be a MONUMENTAL time saver.
Even with display improvements, accelerated hardware and scene/object optimisation, I ALWAYS get to a point where my scene gets so large my display becomes too slow to use. I often have >1GB files with tons of meshes imported from other programs and the only way to operate effectively in Layout space with multiple details is to either turn off the objects or turn off / hide the Details.
For example, I’ve just finished a set of drawings where there was so much being displayed on the Layout that even editing or moving a text object in Layout Space was excruciatingly slow. I would either turn off all my ModelSpace objects, or turn off Details while editing the Layout space objects. I would even move details and edit dimensions using my memory of the displayed Detail objects because actually displaying them would grind my productivity to a near halt!
One particular Layout took minutes to get from “Ctrl P” to displaying the Print Dialog. I could never actually work on this Layout with all objects turned on. I basically turned off as much as I could until I was ready to print, turn everything on, Print, then turn everything off.
An option to turn off redraw per detail would be an absolute GODSEND! If I could print these Details while redraw was turned off, that would be absolute MAGIC! And being able to snap to objects that were ‘not drawn’ would be MIND BLOWING.
Recently I was trying to write a Rhinoscript that cycles through each detail and disables redraw - it appears redraw is global at the moment, so either everything is updating or nothing is updating.
If redraw could be enabled/disabled per view/detail this would massively speed up working in the layout space when there are lots of objects in the scene.
@pascal would this function be possible in a rhino or python script? I’d like a way to work in the layout space with ‘paused’ details, then update when printing.
I thought another possibility was to capture each detail to file with ViewCaptureToFile, then paste them back within a pictureframe. ViewCaptureToFile takes a screenshot of the entire layout space though…
In the meantime I made a script to toggle all layout viewports to wireframe, then back to a more intensive style for printing, if that would interest you @Andrew
thanks for your input, that is exactly what my problem is.
I have tried to open some of our big drawing files in V6 and things have improved a lot in that area, but depending on what one is doing in layout there is still a limit to hit.
I think if all the inactive details would be cached bitmaps or alike, and only the detail being edited needs full redraw things would scale much better.
I think whatever display speed improvement there will be gained from now on will not be enough to alleviate the issues surfacing in this topic.
I agree with the possibilities of confusion and extra bug reports. However that IMO is fairly easy to overcome with a gui with the proper feedback and as such a challenge that can be overcome.
Eg a locked detail will be replaced with a bitmap overlayed with a partially opaque padlock. Double clicking will unlock and to lock you set a checkbox in its properties.
Still, leaving it as-is, will maybe get less bug reports and support requests as it will be regarded as a result of Rhino’s poor limits rather than specific issues that need solving. Keeping it off the tech support radar but not solve anything for the user.
V5 already is stated as being improved for larger files but if layouts with many details bring it to a crawl that statement cannot be held up.