Separate base classes for ICurve geometry and other implementation
We use ICurve geometric abilities extensively (IntersectWith, ClosestPointTo, PointAt, TangentAt, etc... ). This works great.
The entities that implement ICurve (Line, Arc, CompositeCurve, etc etc...) are all derived from Entity class which stores mostly data used for rending and unrelated to geometry (MaterialName, LineWeight, Color, etc etc...). Of course, every new instance takes memory on the heap, time to allocate and time for GC to cleanup... in 99% of cases, this is perfectly acceptable... the issue occurs only with massive datasets.
My thought is to separate the objects used strictly for geometry from the objects used to render. I have some thoughts on how this could be accomplished which I can expand on if requested.
For a practical explanation of how this can help... a user created a file who's size is 1GB and is comprised of 95%+ ICurves. When the same is file loaded, task manager shows 9GB for the running process. My guess is this could be fully described in 1/3 the filesize... I would also expect the overall performance of the running process to improve.
Of course it is so important to keep the simplicity of drawing these Entities. The way Eyeshot works now is so easy to learn and use... I absolutely love it... I think there is a way to accomplish both requirements.
-Jas
Comments
Hi Jas,
We are already working on this, the separation of the Siamese twins (geometric kernel and UI). Another discussion here: https://devdept.zendesk.com/hc/en-us/community/posts/360005919439--NET-Core-3-0-support-at-least-for-geometry-kernel-
Ah yes, I had seen this discussion. I guess I overlooked the details because I am not using .NET Core at the moment...
This is great to hear. I guess this will be implemented for .NET Core and not .NET framework?
My main application relies on multiple .NET libraries. So switching to .NET Core maybe possible, but is likely to be painful for me. However, since .NET will be replaces with .NET core, it is a probably a good decision for Eyeshot...
Thanks for the response.
Jas,
Separating geometry kernel and UI is the first step toward .NET Core support and from what I can understand, this first step is exactly what you are after. Isn't it?
Yes, this concept is exactly what I am looking for. I'm a little hazy on the details still.
Maybe I misunderstood, I was under the impression that the separation of geometry kernel and UI would be done only under .NET core? Or will this separation first be done and released for .NET framework?
I know very little about .NET core, so if I must migrate to .NET core, this is likely a bigger project for me.
Please sign in to leave a comment.