Hi folks!!
I start this thread so that we can decide where to keep all those good future ideas for code improvement that appear from time to time in some threads, but that for whatever the reason, can not be implemented right at the moment.
Trying to be clear, this is for code improvement, not for feature requests or change requests.
For example, dealing with one of my pull requests Werner suggested that the object on object should be done using Inventor scenograph via SoAnnotate nodes, instead of tweaking the z layer (as most of the sketcher is done now). Another example, long ago (I speak relative to my FreeCAD age, which is some 4 months) mrlukeperry raised a similar question with regard to highlighting of lines that are covered by another line (overlapping lines).
I think it would be great to have a place where we can add all those good ideas, so that when someone has time and wants to work on this, (s)he does not start from zero, and is guided in the right direction. I do not know if this should be a sticky post here, mantis tickets, a wiki somewhere, but I think we should have something.
What do you think?
Sketcher WB: Identified areas of coding improvement
Forum rules
Be nice to others! Respect the FreeCAD code of conduct!
Be nice to others! Respect the FreeCAD code of conduct!
Re: Sketcher WB: Identified areas of coding improvement
OK.
1. Solver use sparse matrices. This was suggester by logari81 (he has also started an implementation). I just got it to compile and run. Got excellent results on some cases and crashes in other cases.
Related: look at what Cloud Invent were doing (there's also something on youtube).
2. Redundant work by the sketcher (and possibly other modules). When you are doing a compound change (that's affecting multiple constraints by a single GUI transaction. Eg, you select many lines and then add an "equal" constraint) The solver and the GUI are doing an update for each added constraint. If the sketch is already referenced by other objects a recursive update is done. (eg, the sketch could be used by a pocket and the pocket by a multi-transform operation).
1. Solver use sparse matrices. This was suggester by logari81 (he has also started an implementation). I just got it to compile and run. Got excellent results on some cases and crashes in other cases.
Related: look at what Cloud Invent were doing (there's also something on youtube).
2. Redundant work by the sketcher (and possibly other modules). When you are doing a compound change (that's affecting multiple constraints by a single GUI transaction. Eg, you select many lines and then add an "equal" constraint) The solver and the GUI are doing an update for each added constraint. If the sketch is already referenced by other objects a recursive update is done. (eg, the sketch could be used by a pocket and the pocket by a multi-transform operation).
Re: Sketcher WB: Identified areas of coding improvement
In other projects I've worked with, the bug tracker is the place to put these sorts of things. There is usually a way to specify that an item is a "feature request" rather than a problem that needs to get fixed, and links/tags/etc can be used to connect related items. -Ian-
Re: Sketcher WB: Identified areas of coding improvement
There is also the issue that the solver is called numerous times for each single GUI action. This could be enhanced.
Re: Sketcher WB: Identified areas of coding improvement
I remember that some years ago somebody contributed a patch which reduced the number of calls of the solver. Does anybody know what happened to this patch? Was it integrated into master?ickby wrote:There is also the issue that the solver is called numerous times for each single GUI action. This could be enhanced.