V6 Goal: Display Performance

Hello Steve
in the latest versions, I noticed a significant slowdown when I move the geometry with the gumball or with the cursor or move the command. Even disabling the opengl does not change anything, but it’s all in rhino 5 more fluid
This is the configuration of the PC

HP Z420 Base Model Workstation

AMD FirePro V7900 (FireGL V) - 2048.0 MB
DriverVersion: 13.352.1009.0

Intel® Xeon® CPU E5-1650 0 @ 3.20GHz
NumberOfCores: 6 NumberOfLogicalProcessors: 12
MaxClockSpeed: 3.2 GHz

TotalPhysicalMemory: 16.0 GB

Microsoft Windows 7 Professional

  • Service Pack 1 - 64 bit

Rhino 5 sr 9 64 bit

I don’t know of any recent changes to the gumball code which would affect display performance. @mikko do you know of any?

sorry use google translation
is not the gumball, but the movement of the geometry slowed when the move


non è il gumball ,ma il movimento della geometria rallentato quando la muovo

@clement, can you tell if this is isolated to point clouds or does the scene in general get slower when the gumball is on for other geometry types?

@stevebaer , I don’t know of any changes to gumball that would affect performance. The post also says gumball, nudge, and Move command all show the same symptoms, so it doesn’t seem gumball related.

occurs with gumball, drag, move and copy
Display.zip (3.0 MB)

Hi @stevebaer, i can confirm that the breakdown in display speed is not only related to the gumball but maybe to the selection. Using a open polygon mesh: 3834484 vertices, 7668948 faces, i got these results

  • TestMaxSpeed (mesh selected, gumball OFF) = 18.9s
  • TestMaxSpeed (mesh selected, gumball ON) = 27.92s
  • TestMaxSpeed (nothing selected) = 0.86s

If nothing is selected if feels like having nothing in the document :wink:


Another example of when I move geometry

drag.mp4 (667.3 KB)

Hi Steve,

I have been in the business of Class A surfaces for automotive applications for at least two decades. Evaluation of surfaces, is the basis on which all the design and modifications are made. One of the perennial problems haunting the industry is the display tessellation of surfaces, especially the trim edges. There is a always a tradeoff between fidelity and speed (resources). The current acceptable deviation of tessellated triangles to original geometry for exterior surfaces, is around .001mm. At this resolution, only a limited amount of data can be effectively analyzed. I think both Alias and ICEM Surf have to deal with this issue, on a day to day basis…

I read somewhere about trim surface tessellation using OpenGL 4 techniques significantly improves the display quality, without running out of resources… and possibly a trim edge representation using transparency masks? (uniform tessellation without densely triangulated trim edges)

Are there any plans to improve the display fidelity and speed in V6? If such a thing can be done, I am sure Rhino would make significant inroads into the Automotive design / evaluation market…

1 Like


I’m new here at Serengeti and I’m not sure it’s discussed yet. I did a quick test with my favorite test model and the display performance seems to be slow like at v5 or slower. I like this test model, because it simulate the situation of my heavy project files from my clients, where I see frame rates around 0.5fps.

What are the plans for v6? I would wait for further test until models like this are displayed faster. Textmaxspeed at my GTX 780 show me something above 20s.



The current display work that is being done is to rewrite all of the low level OpenGL drawing code so it is “driver version” aware. In other words, if a driver is advertising that it supports OpenGL 2.1 then use functions that are appropriate for 2.1. This is a pretty significant rewrite of the display code. We may see some marginal performance improvements with these changes, but more likely we will see improved stability across a larger set of drivers.

Once this is complete we will focus again on performance improvements.

Wow! Sounds like a lot of work, especially if you want the lower end to actually be 2.1. What range of OpenGL versions do you think is practical to support in V6? Won’t the time come where the older OGL’s just won’t hack it for contemporary customer expectations for Rhino performance and features?

It actually turns out not to be a whole lot of work to support different versions once the architecture is in place.

OpenGL 1.2 is the Microsoft software mode OpenGL (non-hardware accelerated). We’ve already written support for that years ago and it doesn’t make sense to drop this since it is very helpful when diagnosing misbehaved drivers.

OpenGL 2.1 is the driver level that VMWare operates at and which many users run (even though we don’t recommend it).

We aren’t sure what the top level OpenGL level we’ll need in V6, but we will need to support at least OpenGL 3.0 since that is when frame buffer objects became part of the core. We are pretty much targeting OpenGL 4.5 since that is the most recent version, but it is hard to say if we will need any specific features of 4.5.

I’m hoping this architecture will make it relatively easy to drop in support for a new version of OpenGL when we find a need for it without too much code rewrite. So far, things look good.


The main reason I asked is because I was imagining Rhino using some really powerful new OGL 4.5 features, and you folks having to write lots of work-around code for earlier OGL versions.

Of course I suppose you could just use some boilerplate code that puts up a message box that says something like “Nyah, Nyah you can’t use this feature because you’re too cheap to get a computer that supports OGL 4.5. HaHaHaHa!”

There will definitely be things that just don’t work when running on lower version number drivers. This already happens on Rhino where you get antialiasing through multisampling when the driver supports is. Other features like shadows drop out when running on non-hardware accelerated OpenGL.

I see. Of course.

Does John Brock get many questions like “How come my coworker (friend, client, etc.) has neat shadows and swell looking curves?”

OK, good luck for coding. So I hope the freezed parts of the display will be gone in the future.

Best post a note if you are working on the display speed for models like the bike and you need more tests. Using more GPU power is very missed here.

Hi @steve, @jeff,

Not sure if this is the right place to put my post but…

Have noticed two small issues in the latest WIP (it can be that it has been touched before)

  1. Seems that points (exc. when drawing a curve) are not displayed correctly ->rectangle is not present around the point. When zooming in/out - works as normal. See enclosed.
  2. Height of the help textbox (whatever is the right name) is higher than needed -> mouse can be seen twice. Also enclosed.


In fact, the tooltip boxes are too small, they don’t show the right-mouse click option.