I am coloring a large, 238M pts pointcloud to show an elevation map using an Eto-Forms GUI to select the colors. To help in color selection, there is an interactive color legend that displays Available Colors/Elevation Data/Elevation/Color:
Then the blue curves between the Available Colors/Elevation Data/Elevation columns move to show the new selections. Currently these curves are deleted and then added back to the Rhino Document with each click in a wheel rotation while doc.Views.RedrawEnabled = False. Then once the curves have been added to the document, doc.Views.RedrawEnabled = True is set and a redraw occurs showing the curves in their new location. The redraw takes so long that the interactive nature of rotating the wheel and moving the curves is not very smooth.
My question: If a Display Conduit was used to display the geometry of the curves while the wheel is rotated, is there a way to redraw just the curves and make them visible and nothing else in order to provide a much smoother interaction?
I played with the Python DisplayConduitSphereExample and see how the conduit works but that example uses doc.Views.Redraw() which is not what I want.
I noticed that CRhinoDisplayPipeline has a DrawCurve function. Would using this be a way to draw only the curves and nothing else?
Thanks for the response. My timings show that 10% of the time is spent drawing the curves and 90% is spend doing the redraw. Its good to know that using a display conduit could reduce the 10% portion of the time. But is there anything I can do about the 90% portion of the time spent on redraw? Is there a way to tactically remove the old curves and just draw the new curves? In my case the curves do not pass over anything else so it would be possible to erase any pixels in that area and then put in the pixels for the new curves. But perhaps Rhino cannot give me this level of control?
The drawing speed seems not to be a problem as it comprises only 10% of the time to see a new curve. Essentially all of the time goes into making what was dawn visible by doing a doc.Views.Redraw(). Also I need to remove the prior curve that was drawn but this should be OK as I just need to disable the conduit for the prior curve, right?
SO THE KEY FACTOR IN QUICKLY DISPLAYING A SERIES OF GUIDE CURVES IS: HOW TO MAKE THEM VISIBLE AFTER CREATING THEIR DISPLAY CONDUIT WITHOUT TAKING ALL THE TIME THAT doc.Views.Redraw() REQUIRES? THIS IS A KEY QUESTION; I NEED TO UNDERSTAND BETTER HOW Redraw WORKS.
Remember I have a large pointcloud displayed with 2 to 7 GB of data and so Redraw may be impacted by this.
We are on different pages. Drawing the curves essentially takes no time. Being able to see them, which requires a redraw, takes all the time.
The curves move from one place to the next, so the old curve must be removed when the user rotates the wheel to select another value in the color legend. The new curve needs to point to this new location. This is dynamic in time so I cannot not draw the curves I don’t want as I do not yet know which curve is going to be removed until the user decides.
Is there a way to make redraw faster? This is what I believe I need from working with the Sphere example where if I turn off redraw I cannot see the mesh that is generated by the display conduit.
Perhaps I need to make a series of snapshots that shows the progression of the curves as the mouse wheel is rotated so you can better understand what is happening.
But no matter what, my current understanding is that using a display conduit does nothing you can see unless a redraw is issued after the conduit is enabled. So unless redraw can be as fast as the conduit drawing of the curve, then there is no benefit to using a display conduit for my application which is waiting 90% of the time for the redraw to finish.
I did some more experiments with the Sphere display conduit example in order to better understand how redraw works. This is what I learned:
The first redraw after enabling the conduit is slow, taking 3.2 sec, when I use CreateFromSphere(sphere, 2000, 2000) which makes a very dense mesh.
A second redraw after this is much faster, 0.012 sec.
When I place the sphere in the same document with my 39M pts pointcloud, the second redraw slows down to 0.039 sec.
When I place the sphere in a document with my 238M pts pointcloud, the second redraw slows further to 0.169 sec.
Thus the redraw time appears to be sensitive to the amount of data being displayed. While the pointcloud is a single object in the Rhino Document, its presence significantly grows the memory footprint of the Rhino session. Perhaps this has something to do with the redraw time slowing?
Based upon this, I changed my form to hide the large pointcloud while the curves are updated and obtained a very smooth interactive behavior between changing the value on the form and the curves updating in the color legend; hiding the pointcloud improved the redraw time to show the updated curve locations from 0.85 sec to 0.01 sec.
Does this Redraw timing behavior make sense to you? I have attached the modified Sphere display conduit example below so you can try it yourself. Place a sphere in different documents with different amounts of data and watch how the redraw time varies.
