DG Kernel Forum

I have a couple of questions.

1) We have two controls on a form. We noticed if the split view is disabled and we are only drawing to one of the CAD controls we didn't see a significant performance boost. Is this expected?

2) Is there a way I could update the model via axKernCADnetFront.UpdateView() from a non gui thread? A large part of the performance problem is not that KC is taking too long to draw. It's that KC is one of the many components that has to update. So if KC requires 200ms for each draw and we want to draw at 4Hz then KZ would be trying to utilizing 80% of the gui thread. 4-5Hz redraw should satisfy our requirements but only if it doesn't impede our other controls. Do you know of any way to safely decouple the two, is it possible for an activex control to draw outside the .Net GUI thread without major ramifications? Or is it possible to render to an offscreen bitmap on a separate thread then just use the gui thread to update the screen from the bitmap.

JM

KC does not handle the Visible and Enabled windows styles. It is not aware of it directly.

We believe KC is the fastest among comparable components. If you do not update the view KC does not take any processor cycles. What you are writing about happens only if you do continuous animation of many things.

The view displayed in KC window is cashed and is not updated until it is necessary. For example it is not regenerated even if you move the window around without changing its size. So if you hide or disable the window and do not call any methods or interfaces KC is sitting idle without doing anything.

You can test the above: Open any KC sample, Open Windows Task Manager>Performance tab. Rotate (shake) vigorously the KC view. You will see the CPU usage going up, but when you release the mouse it goes right down to nearly zero.

KC can do off-screen rendering (Capture sample), but I am not sure about doing it on a non-GUI thread. I am not sure it is worth the effort either as rendering pretty fast and it is normally done when the user interacts with the window, so KC is expected to work with high priority. It might make more sense for slow geometry processing like complex Boolean Operations.

Since v7.1 DGK has an option of sharing model between two or more views. It significantly increases performance and memory consumption. See Multi View sample for an example.