Hi all,
I’ve noticed that Grasshopper in Rhino 6 appears to have altered performance when compared to Rhino 5 and run a few tests which would be good to discuss.
This is benchmarked as follows:
A basic, arbitrary definition where a box moves around in a circle with a random population of mesh spheres. The only plugin used is Human for the HUD (does not affect performance comparison). The definition is still functional without this and results can be displayed in panels.
The computation time is measured (when the first component gets triggered, when the last component gets triggered)
The refresh time is measured (the time taken for the definition to recompute and trigger the same component)
The refresh time is approximately 200% when comparing 6 to 5. The computation time is comparable.
Hence I suspect either:
The display pipeline is slower, or
The time taken to mark the solution as ‘complete’ is longer (to allow the timer to trigger another update)
Some other notes:
Rhino 5.14.522.8390 vs Rhino 6.3.18090.471
Windows 10, XPS13 9370 (no dGPU)
4K screen with 200% DPI scaling - this may be relevant
Attach screenshot of the definitions side-by-side, video example, and the definition itself.
Disabling the display on both still shows 5 performing twice as fast as 6.
Making the Rhino 6 viewport very small leads to the refresh time converging if geometry display in grasshopper is disabled (in my case to about 40ms). When geometry display is still enabled the performance is closer to the same, but 6 is still 20-30% slower than 5, regardless of window size.
Attached new screenshot illustrating this effect. Note that as a snapshot the numbers vary and this is indicative only.
This may still be consistent with the display being slower. Just because Grasshopper doesn’t draw anything in the viewports doesn’t mean the viewports aren’t refreshed.
Since the developer with whom I’d have to look into this is currently travelling, we’ll have to get back to this in a couple of weeks. I’ve logged it under RH-45797.
In the meantime, can you confirm that if Grasshopper isn’t loaded at all, the _TestMaxSpeed command yields comparable results on both R5 and R6? What if Grasshopper is drawing previews, does _TestMaxSpeed show the slower performance?
On a blank document, no Grasshopper loaded, both windows maximized.
5: Time to regen viewport 100 times = 0.25 seconds.
6: Time to regen viewport 100 times = 0.81 seconds. (123.00 FPS)
To clarify if this is DPI scaling related - this is the same test again but with a force viewport resolution of 1280x720 (previous tests would have the 6 viewport much higher resolution than 5 due to DPI scaling of 200%)
5: Time to regen viewport 100 times = 0.42 seconds.
6: Time to regen viewport 100 times = 0.66 seconds. (152.44 FPS)
And lastly, with the same forced viewport size (1280x720) and Grasshopper previews enabled:
5: Time to regen viewport 100 times = 0.86 seconds.
6: Time to regen viewport 100 times = 2.91 seconds. (34.41 FPS)
So interestingly, with the same size viewport, enabling the grasshopper preview results in 200% display time in 5, but 450% in 6.
When I get a moment I’ll run the same test with some Rhino geometry (as this may be entirely unrelated to Grasshopper after all)
As promised - the same test with some geometry in the viewport.
Set up is as before. 1280x720 viewport. Baked objects (mesh spheres) from Grasshopper. Both using shaded view, no mesh wires.
5: Time to regen viewport 100 times = 0.61 seconds.
6: Time to regen viewport 100 times = 1.59 seconds. (62.74 FPS)
In the above, both 5 and 6 are using (the default) AA 4x
Disabling AA shows the following:
No geometry in scene, 1280x720 viewport:
5: Time to regen viewport 100 times = 0.20 seconds.
6: Time to regen viewport 100 times = 0.23 seconds. (427.35 FPS)
Geometry (100 mesh spheres) in scene:
5: Time to regen viewport 100 times = 0.53 seconds.
6: Time to regen viewport 100 times = 0.23 seconds. (425.53 FPS)
Removing DPI Scaling - now a 4K screen at 100%, but only testing on a 1280x720 viewport
No geometry in scene:
5 : Time to regen viewport 100 times = 0.27 seconds.
6 : Time to regen viewport 100 times = 0.23 seconds. (425.53 FPS)
100 mesh spheres in scene:
5 : Time to regen viewport 100 times = 0.55 seconds.
6 : Time to regen viewport 100 times = 0.84 seconds. (118.48 FPS)
Base on the above, this doesn’t seem related to Grasshopper, but R6 display in general. Let me know if you’d like me to run some more tests and/or move it to another area of the forum.
Much will depend on your GPU, but the V6 speed improvements will shine with lots of geometry on your screen. When I use my Intel HD 630 I get \approx6s for 1000 spheres on screen in v6, but \approx9s in v5. Now, if I use my GTX 1060 I get \approx9.5s in v5, similar to the v5 time, but in v6 I get under \approx1s.
This may also have to do with the specific grasshopper test that was presented. The new display code performs a lot of caching of data on the GPU to improve performance when the same object is drawn multiple times (which is pretty typical). In this case it looks like a different object is being drawn every frame which may result in slightly worse performance.
@stevebaer That’s correct in the case of the initial Grasshopper test, but I’m still not sure in the case of just viewing (non-gh) spheres. We typically use grasshopper in an event driven or timer based fashion which indeed causes rapid refreshes of geometry (including things like Kangaroo simulations).
Now, I realise that the (lack-of) GPU isn’t the most powerful as this is running on a high end ultrabook with Intel UHD Graphics 620.
I’ve done a little more testing to hopefully narrow down the cause a little. The following are testing Rhino alone with no non-standard plugins loaded.
5: Time to regen viewport 100 times = 0.67 seconds.
6: Time to regen viewport 100 times = 0.44 seconds. (228.83 FPS)
AA 8x
5,: Time to regen viewport 100 times = 0.86 seconds.
6: Time to regen viewport 100 times = 1.23 seconds. (81.04 FPS)
Based on the above - it seems the source of the issue may actually be to do with AA, as it appears to cause a small performance hit in 5 and a large one in 6.
Are there any other tests I can run to help verify these results or narrow the issue?
This does look related to the Intel GPU and its associated driver. Increasing the AA really shouldn’t change the performance that much. @nathanletwory are you using the same driver version on your Intel 620 that @camnewnham is using?
Hi,
I am experiencing something similar (very significant display performance drop - around /2 - between RH5 and RH6 when animating wireframe and meshes displayed via GH conduit) on my computer (sysinfo below).
I can reproduce the drop by using regular GH components (just moving spheres like proposed above), so it seems that it’s not linked to my code.
Just in case: @stevebaer -> is there a new recommended drawing method to be used when we already cache animated geometry ourselves, and have to display it via GH? (CustomRenderMeshProvider2 ?) I am only starting to test RH6 now, so I am not sure if using the GH conduit via DrawViewport overrides is still the preferred method in GH for RH6. Being able to stick with DrawViewportXXX would be very nice though, as it’s backwards compatible with GH for RH5…
There was a caching feature that dramatically improved the GH display performance that we had to pull right before initially shipping V6 due to some bugs that we didn’t fully understand at the time. Jeff Lasor recently fixed this issue and we should be seeing performance improvements in Rhino 6.6 which should be available in a few weeks as a release candidate. @thibaultschwartz, I don’t think you need to change any of your code.
Given that in this instance I also get better performance for non-grasshopper geometry (when the scene is simple/small) with Rhino 5 - potentially the AA issue above - is there anything else I can test here?
Just one last check - I have tested on a few PCs with different configurations. It seems like the issue is largely due to high DPI displays. For example, when running a 3840x2160 display at 200% DPI scaling, Rhino 5 will render a ~1600x900 viewport when maximized, whereas Rhino 6 will render 4 times that.
Whilst this is ideal in some scenarios (ie. on a large format 4K display) this is potentially problematic for ultrabooks and retina displays - and subsequently in meetings/presentations. Is it possible (now or in future) to have an option to change the DPI scale/resolution of the viewport(s)? Ideally without changing the DPI of the entire program.
