fougue
In "inspect XDE", entries are not displayed correctly after a hot reload
Hi @HuguesDelorme, thanks again for fixing bug #332!
While testing the latest build from the develop branch, I noticed that the entry labels are not updating correctly after a hot reload. It looks like the old or previous counter value is still being used.
I didn’t have time to dig into the code, but I hope you can quickly figure out where the problem is.
Greetings
I can't reproduce the issue you reported with the STEP files I have which trigger "auto naming" feature from OpenCascade(see XCAFDoc_ShapeTool::SetAutoNaming()). Those auto-generated names are "correct"
Can you attach the STEP file you are using?
Hi @HuguesDelorme sorry for the delay, I was on vacation for a few days...
It doesn’t matter which STEP file you use, the problem is always the same!
But here’s a very simple STEP file with 2 solids (test_simple.stp.txt) so that you can reproduce the issue more easily.
In the internal XCAF document, they show up as 2 separate shapes ("axle1" and "axle2"):
0:1
├── 0:1:1 Shapes
│ ├── 0:1:1:1 axle1
│ └── 0:1:1:2 axle2
├── 0:1:2 Colors
├── 0:1:3 Layers
└── 0:1:4 ...
When the STEP file is updated in the background and Mayo reloads the model after change detection, the "inspect XDE" dialog shows different entry for the label for the two shapes:
You can simulate the update of the STEP file by changing the timestamp in the header, for example – just modify the timestamp and save the file so that Mayo detects the update.
From my point of view, the problem doesn’t seem to be related to writing or setting names / entry for the label.
When I add a debug output for the label-entry in the deepLoadChildrenLabels() method – where you collect the data for the Inspect XDE tree – I can see that after each hot reload of the STEP file, more and more "childLabels" exist in the background (see marker 1 in the screenshot). However, these are ignored by the if condition because they don’t have any attributes. Since only the ones with attributes are displayed (if condition is true - see mark 2 in the screenshot), the last-tag-shift in the label-entry happens after each hot reload of the STEP file.
This leads me to the question whether the cleanup of the "old" model during hot reload might still not be working properly – maybe not all old objects are fully removed before the new model is loaded again. Could that be the case?
Unfortunately, I don’t have time right now to look deeper into your implementation. Depending on how you manage your model internally, it might be that your instance of "XCAFDoc_ShapeTool" is still holding an outdated internal cache, which could cause the elements under the main label to not be handled correctly?
I hope this can help, thank you for your work and efforts greetings
Hello @dabari
Thanks for your extensive and detailed comments
There's actually nothing wrong with the increasing "tag counter" of the axle1 and axle2 labels.
The labels owned by a document can't be deleted, that's an OCAF(OpenCascade Application Framework) limitation.
Only the attributes(ie the data) attached to a label can be deleted. A label can then become "empty", having no attributes, but again it can't be deleted.
See the OpenCascade reference manual about labels:
https://dev.opencascade.org/doc/overview/html/occt_user_guides__ocaf.html#occt_ocaf_3_4
"Label can not be deleted from the data framework, so, the structure of the data framework that has been created can not be removed while the document is opened"
So when reloading a document, Mayo first clears all the attributes attached to existing labels in the document and then import the entities from the file again. There's no issue actually, I understand it's weird to know"old" labels are still there, but they are empty after the reload.
Hi @HuguesDelorme,
thank you very much for your feedback. I now better understand your perspective and can more clearly assess the way you implemented and handled the function.
Unfortunately, the limitation of OCAF at this point has a significant negative impact on the consistency and reliability of the "debug" information that the "XDE Inspection" in Mayo is intended to provide.
For example, when a STEP file (see marker 1 in the image) is changed, the old labels remain in the OCAF document. The newly visible shapes then receive "tag counter" that start at a high index (see marker 2 in the image). The larger and more complex the STEP model, the wilder the index allocation.
If the same STEP file is opened in a Mayo instance without hot reload - or simply opened a second time - the XDE Inspector displays another (correct) tag numbering (see marker 3 in the image). However, this numbering differs from what is shown after a hot reload.
While it is clear that the tags have no semantic meaning and are merely unique IDs, this behavior can still be very confusing for users, particularly because the XDE Inspector is often used to better understand the underlying XDE model.
Given this limitation of OpenCascade, I believe a cleaner approach would be to ensure that a hot reload completely discards the old OCAF document and creates a new one upon reload – just like when the file was first opened.
Thanks and best regards