Paths falsely marked as altered. ( part 2 )

[freman]

Hi,

I'm reposting this issue which highlights a bug which is important for 3D paths where unnecessary recomupation matters since computation times can be very long. The previous thread has wandered off into a totally unconnected discussion.


I have just noticed that when "Skip Computes" is checked at the top of the treeview, any attempt to edit a path gets it a little blue tick mark indicating that it needs updating. This happens even if you cancel out of the path edit, ie no changes were made.

Same applied to editing a tool controller from the tree. Double click to edit and cancel out , then all dependent paths using that tool get marked for re-computation.

This was noted on both 3D Surface and Profile paths.

Since 3D paths can be extremely long to re-compute, it would be nice to fix this. It seems there is some error in taking account of "dirty" flag when "Skip Computes" is active.


OS: Fedora 34 (Thirty Four) (LXQt//usr/share/xsessions/lxqt)
Word size of FreeCAD: 64-bit
Version: 0.20.26155 (Git)
Build type: Release
Branch: master
Hash: 0926a4148bcff11249fd4f56bc30256102ffe105
Python version: 3.9.7
Qt version: 5.15.2
Coin version: 4.0.0a
OCC version: 7.5.0
Locale: English/United Kingdom (en_GB)

[onekk]

From the old discussion came out some hints.

FreeCAD should have a mean to see if something important "is altered", you simply change a "mistake in a string", but the whole object "is altered".

From what Path will know if something important is altered, without reading all the parameters and decide if a "recomputed is needed or not"?

This is the point.

Skipping recompute, involve that a complete refactoring of the PathScripts parts, i.e maybe there should be a CheckValues() method that decide if a complete recompute is needed or not.

some consideration will came in my mind:

1. how much this checking is taking in term of computing time?
2. how much in term of lines of code and code complexity this will involve
3. maybe this checkValues() should be inserted as a "step of the workflow", in other word, checkValues() is triggered in two cases:
   1. when an operation is created prior to create the path as a sort of "value validation", maybe shortening other code around. (but it heavily depend on how the code is done)
   2. when a values is modified, to decide to fire or not a "full path recompute"

This is only from a "coder" perspective, user perspective could be very different.

Maybe this will be some "alternative way of doing things", that maybe (too much maybe without some code analysis) will lead with some developers efforts in something more concrete.

Take it as a tentative of "constructive thinking".


Regards

Carlo D.

[chrisb]

There sure is room for optimization, but I wouldn't call it a bug: no error is thrown, no wrong path is generated.

[freman]

Marking a path as requiring recalculation when it is unchanged is WRONG. It is not intended behaviour, therefore it is a bug.
Arguing about how serious the bug is does not change whether it is a bug or not.

I have had 3D paths which take over five minutes to recompute. I REALLY do not need that happening unnecessarily: I can only drink so much coffee in one day !!

There is a BUG in the code when "skip computes" is activated which labels unmodified paths as "dirty". This does not happen on the same paths when "skip computes" is not checked. This seems to be a simple logical error, not something requiring a redesign, rewriting or "refactoring" of the code base. The mechanism is already there for 3D paths when "skip computes" is not active.

[freman]

Another error in this bug is that with "skip computes" active doing Path | Post Process, marks the job as needing recomputation in the tree. However this is being done is not based on real conditions. It seems to mark everything as a recomp as soon as it is touched, even if nothing is changed : as in a cancelled edit , or the post-proc which does nothing but read it.

Again this is a bug, because it is highly detrimental to work flow when path ops can often take several minutes each to recompute plus this is being done totally unnecessarily.

This should at least be recognised as a problem.

[chrisb]

I didn't mean to leave it as is.

[sliptonic]

Marking a path as requiring recalculation when it is unchanged is WRONG. It is not intended behaviour, therefore it is a bug.
Arguing about how serious the bug is does not change whether it is a bug or not.

Yes. And also no.
If you had said "path object" instead of just "path" I would have agreed entirely. The featurepython objects are recomputed as a whole and the toolpath is just one property. If you change another property of the object which doesn't affect the toolpath (e.g the label) it marks the whole object as dirty and the whole thing will be recomputed. That may be undesirable but it is correct behavior.

However, there are cases where NOTHING is changing and the object is still marked dirty. First priority is to fix this.

[freman]

However, there are cases where NOTHING is changing and the object is still marked dirty. First priority is to fix this.

Yes, that would be great. Currently I'm wasting loads of time with things recomputing for no reason. I go in to check a detail of some feature, exit out with cancel and everything starts chugging away for another 10min redoing everything I have not touched.

It seems Russ fixed 3Dsurface since this seems to be the only path op which does not come out dirty when I cancel out. I think I commented at the time that 2.5D tools were also doing this but they were fast enough to this not to be too important. I now have a profile path which is taking several minutes which makes this a real issue.

I reported this as an issue with "skip computes" but it maybe that this is just the blue check marks making obvious what was also happening with auto updates, except that most 2.5D paths are quick enough that this is not noticeable.

[freman]

That may be undesirable but it is correct behavior.

OK, buggy by design
There maybe need to for two binary flags in this case ( assuming that changing a label matters to anything, that it needs to be flagged in the first place). Maybe a separate dirty_path binary for anything which actually ( or potentially ) invalidates paths.

As you say , priority is avoiding setting flags when nothing is changed ( especially when user literally cancels out ).