The tasks scheduled for the current iteration are:
- Rebuild the tree view logic to display references as child nodes, estimated 6 hours,
- Apply on the tree view the model tree changes, estimated 3 hours,
- Propagate tree modifications (parametric modeling for the new data tree), estimated, 1 day,
- Extrude improvements, estimated 2 hours,
- Port Action2D to work with multi click instead of dragging, 1.5 days,
- Port Action3D to work with multi click instead of dragging, 1.5 days,
- Extract 2D actions drawing code to work in 3D (ex: drawing a line in 3D), estimated 4 days,
- Make the geometry solver to work with the data tree, store solver attributes on the data tree, estimated 3 days,
- Add code that displays magic geometry, estimated 1.5 days.
On the iteration will be made also code refactoring, bug fixing and documentation update.
Subscribe to:
Post Comments (Atom)
3 comments:
Hi.
I know that OCC6.3 have memory leak problem.
Do you have solution or plan of the problem?
Thank you~
Hi,
After we will have a functional version of Naro for sure we will start patching OpenCascade. If we will be lucky maybe until that moment OCC will release an improved version.
Best regards,
Mihai
Hi,
I think that OpenCascade in itself is not so leaky. The biggest reason for leaks in OpenCascade is the Handler_[class] structure, which is a reference counted smartpointer. This makes that circular references to not be disposable, and is not a problem of Opencascade per se but is a problem of C++ usage.
We cannot pretend for a such big project as OpenCascade to not have leaks at all. All non garbage collected languages have a potential problem with leaks.
My personal note is: if we use C# references and we avoid Handle_ classes usage, we will keep the leaks low. If we find a functionality that always leaks in OCC, we will try to avoid it, or if is not possible, we will use it, and submit a patch to OCC to be fixed in the next version. (as Mihai said)
Bests,
Ciprian
Post a Comment