Sure. Rhino is a NURBS modeler. If I oversimplify quite a bit, OpenGL draws triangles and lines. OpenGL can’t draw NURBS (very well). We convert smooth NURBS surfaces to polygon meshes, and smooth NURBS curves to polylines to send to OpenGL.
For surfaces and solids, we mesh once and save the mesh in the file. Steve and Jeff’s work has been to cache those meshes on the video card, so there’s less geometry moving from RAM to the card. That’s the primary speed up you’re seeing today. They’ve also done a lot of work rearranging our OpenGL code so that it can use more modern features and syntax, while also degrading gracefully on older cards. We are optimistic that by doing this we’ll see not only performance improvements but also stability improvements over Rhino 5 (display instability is tied with install failures as our #1 tech support headache in Rhino 5).
For curves, surface edges, and isocurves, we create the polyline approximation for every frame draw. The polyline approximation is done to sub-pixel accuracy so that curves in Rhino always look “correct” no matter how far you zoom in. This was really novel when we first did it, and it made Rhino’s display look really nice without having to manually “regenerate” the view, or without sending 1000-point polylines for each curve when zoomed out to the point that 4 points would do. The polyline approximation is computed on a single thread on the CPU - because this code was written years ago when there was only one or two threads at a time on a computer, and before OpenGL supported fancy shaders.
We know its possible to speed this up. Its possible to do some of that work on the GPU, use multiple threads on the CPU, and intelligently cache some of this information so that the computations happen less frequently. But all of those solutions are pretty substantial projects, and we probably won’t complete any of them before Rhino 6 ships.