Discussion: slow down in document loading and recomputing

Discussions about the development of the TechDraw workbench
vocx
Posts: 3357
Joined: Thu Oct 18, 2018 9:18 pm

Discussion: slow down in document loading and recomputing

Postby vocx » Sun Aug 25, 2019 9:22 pm

With he recently merged LinkMerge branch, realthunder has mentioned a few problems with TechDraw. I don't have deep knowledge of these problems but I think it's important to at least document and discuss the issues. Realthunder is a bit of a wizard, so who knows, he may just refactor TechDraw in a whim and fix everything.
realthunder wrote:
Thu Aug 22, 2019 11:01 am
... The recompute touch problem you've experienced is caused by two bugs in Datum and TechDraw objects which I've fixed also. ...

There is one suggestion. The current TechDraw workbench seems to have many problems, causing slow down in document loading and recomputing. I'll propose some fix later when I have time. But even with the fix, I would suggest you to move the drawing out of the assembly. ...
Does this mean move the TechDraw Page to a separate FreeCAD file .FCstd?
realthunder wrote: When you put the drawing inside a part container, everytime the part is updated (e.g. moved), it has too recompute all its children first, including the drawings. TechDraw update takes time, lots of time if comparing to mere placement updates in links and parts.
What? Why would somebody put a TechDraw Page inside a Part container? I assume a Std Part (App::Part)? This seems completely counter-intuitive, as a drawing isn't a physical part, it's just additional data that depends on the other physical objects.

I assume the intention was to keep the physical object together with its drawing. Would a Std Group not work better for this?

@user1234, why do you put a TechDraw Page inside a Std Part?
user1234 wrote: Ping
realthunder wrote: It would be better if you put drawing in its own document, and use link to bring in any necessary parts. This way, when you modify your main assembly, and hit that recompute button, the drawing document won't get updated, because the assembly does not depend on the drawings. It is the other way round, and it should be.
So I guess this means that with App::Link now part of FreeCAD we will achieve something that has been requested before: one .FCstd will hold the geometrical bodies, or assemblies, and a separate .FCstd will hold their corresponding TechDraw drawings. The second file can even have its own extension, .FCdrw for example. This is how it's done in Catia and other commercial systems; there is a file for simple parts, one for assemblies, and one for drawings, and others for different uses.

Also see the realthunder's commit in pull request #2449 to address this issue. He again mentions the problem of unnecessarily touching the children of the TechDraw View.
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.
User avatar
wandererfan
Posts: 3680
Joined: Tue Nov 06, 2012 5:42 pm

Re: Discussion: slow down in document loading and recomputing

Postby wandererfan » Sun Aug 25, 2019 10:17 pm

vocx wrote:
Sun Aug 25, 2019 9:22 pm
With he recently merged LinkMerge branch, realthunder has mentioned a few problems with TechDraw. I don't have deep knowledge of these problems but I think it's important to at least document and discuss the issues. Realthunder is a bit of a wizard, so who knows, he may just refactor TechDraw in a whim and fix everything.
TechDraw is moving from an "always up to date" model to a "update on demand" model as part of the v0.19 development cycle.
This means that all the touch, mustExecute, onChanged and keepUpdated logic in TD is going to change.

RT or anybody is welcome to submit changes to the existing structure, but there is no guarantee of a long service life for the changes.
vocx
Posts: 3357
Joined: Thu Oct 18, 2018 9:18 pm

Re: Discussion: slow down in document loading and recomputing

Postby vocx » Sun Aug 25, 2019 11:03 pm

wandererfan wrote:
Sun Aug 25, 2019 10:17 pm
TechDraw is moving from an "always up to date" model to a "update on demand" model ...
I presume you refer to this thread Opinions on Major Philosophy Change for TD in v0.19?

I think it's fine recomputing on demand. I was just mentioning the things I've gathered from the LinkMerge discussions. I got the impression that the current model can continue, just with a few changes, incorporating the new App::Link functionality. If the bottleneck, however, is still the OCC routines like the HLR algorithm, then of course drawing speed is still dependent on that.
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.
freedman
Posts: 1268
Joined: Thu Mar 22, 2018 3:02 am
Location: Washington State, USA

Re: Discussion: slow down in document loading and recomputing

Postby freedman » Mon Aug 26, 2019 1:10 am

What this really sounds like is App::link has finally touched TechDraw. This is a good thing I think, App::link is just starting pre-release and the discussion of where to put drawings can start. Of coarse these discussions can have large, long term impacts..... :) I hope someplace in the link strategy there is method to deal with revisions of models. Is it to simple to think we could link a drawing to a model. :)
realthunder
Posts: 1408
Joined: Tue Jan 03, 2017 10:55 am

Re: Discussion: slow down in document loading and recomputing

Postby realthunder » Mon Aug 26, 2019 9:08 am

wandererfan wrote:
Sun Aug 25, 2019 10:17 pm
TechDraw is moving from an "always up to date" model to a "update on demand" model as part of the v0.19 development cycle.
This means that all the touch, mustExecute, onChanged and keepUpdated logic in TD is going to change.
Correct me if I am wrong, because I haven't spend much time with TD yet. Objects like DrawProjGroup holds properties like Scale, etc, which is meant to be used as a convenience for mass changing its children, like DrawProjGroupItem. So the natural dependency order should be recompute PorjGroup first, and then ProjItem.

The problem is that ProjGroup uses a PropertyLinkList (Views) to hold its children, hence the dependency order is inverted. I have added a new LinkScope for just this kind of scenario. Simply call Views.setScope(App::LinkScope::Hidden) in DrawViewCollection constructor, and FC dependency walker will just ignore this link property. You can then add a normal PropertyLink property to all children named, say 'Parent', to point it to its parent. And this tells FC to recompute the parent before the child.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
realthunder
Posts: 1408
Joined: Tue Jan 03, 2017 10:55 am

Re: Discussion: slow down in document loading and recomputing

Postby realthunder » Mon Aug 26, 2019 9:14 am

freedman wrote:
Mon Aug 26, 2019 1:10 am
Is it to simple to think we could link a drawing to a model. :)
Yes, something like that. It is recommended to create separate document for drawing, and use Link to bring in models from other files. This way, when you are working on the model, doing recomputation and stuff won't trigger update in the drawings.
Try Assembly3 (latest version 0.10.2) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
wandererfan
Posts: 3680
Joined: Tue Nov 06, 2012 5:42 pm

Re: Discussion: slow down in document loading and recomputing

Postby wandererfan » Mon Aug 26, 2019 1:29 pm

realthunder wrote:
Mon Aug 26, 2019 9:08 am
Correct me if I am wrong, because I haven't spend much time with TD yet. Objects like DrawProjGroup holds properties like Scale, etc, which is meant to be used as a convenience for mass changing its children, like DrawProjGroupItem. So the natural dependency order should be recompute PorjGroup first, and then ProjItem.

The problem is that ProjGroup uses a PropertyLinkList (Views) to hold its children, hence the dependency order is inverted. I have added a new LinkScope for just this kind of scenario. Simply call Views.setScope(App::LinkScope::Hidden) in DrawViewCollection constructor, and FC dependency walker will just ignore this link property. You can then add a normal PropertyLink property to all children named, say 'Parent', to point it to its parent. And this tells FC to recompute the parent before the child.
Some of the newer stuff "links upward" and uses InList to find children if required, but the really old stuff (DrawPage, DrawProjGroup, etc) tracks children with "downward links" and add/removeChild functions.

Thanks for the tips. I'll look into them. At first glance, the trickiest bit looks to be backward compatibility.

wf
User avatar
wandererfan
Posts: 3680
Joined: Tue Nov 06, 2012 5:42 pm

Re: Discussion: slow down in document loading and recomputing

Postby wandererfan » Mon Aug 26, 2019 1:35 pm

vocx wrote:
Sun Aug 25, 2019 11:03 pm
If the bottleneck, however, is still the OCC routines like the HLR algorithm, then of course drawing speed is still dependent on that.
HLR is still the biggest bottle neck.

The link stuff will help in separating drawing updates so they don't slow down work on the model. Updating a drawing with lots of edges and faces will still be slow.
user1234
Posts: 216
Joined: Mon Jul 11, 2016 5:08 pm

Re: Discussion: slow down in document loading and recomputing

Postby user1234 » Tue Aug 27, 2019 10:11 pm

Hello!
vocx wrote:
Sun Aug 25, 2019 9:22 pm
@user1234, why do you put a TechDraw Page inside a Std Part?
There are more reasons why i do that.

1. That is common in pretty every commercial CAD System, a kind of habituation for me.
1.1 A drawing depends on a part, both should always be together. So both is fixed together, see --> 2.

2 If you do plant construction and engineering it is in an ERP, PDM and PLC easier to handle. If you reuse (company standard) parts in many plants in different customers and assembly files, you need them together, else you will get frittered (is tha the right word? German: verzettelt). For example the company, that i work at the moment, have not thought on that (drawing is not in the part), and this costs my around 15h/week. And now all finalized projects are a mess and anybody finds anything (they linked parts to any drawings, rename it in the ERP, PDM, made some different properties in the drawing and nothing fitted, is different materials, other coatings, ..... only because of this small detail, that is my personal hell).

3. If you make an assemby and if you want to check the drawings, you have an instant access all drawings and you do not need so seach them.

4. Every part should be structured in the same why (for ever kind of part). And its elements should always be relabeled. So i work many with relabel macros. When i am finished with a part, i give it a name (actually relabel) and all elements, objects, ..... relabel with the macros.

5. If you schedule erection, maintenance or repair for plants working for the workers, you give him one assembly in 3D, and he (or today she ot it) have an access to the drawings, that he, she, it needs.

6. Many more .....


Generally it is common (with a good reason), that if you open 2D file, that it do not update. It checks if it needs to update. For example the three element of the draing is red, if the links is missing (common when the drawing is not in the part or not loaded), orange when in needs to update and green when it is up do date.

Greetings
user

ERP https://en.wikipedia.org/wiki/Enterpris ... e_planning
PDM https://en.wikipedia.org/wiki/Product_data_management
PLC https://en.wikipedia.org/wiki/Product_lifecycle
vocx
Posts: 3357
Joined: Thu Oct 18, 2018 9:18 pm

Re: Discussion: slow down in document loading and recomputing

Postby vocx » Tue Aug 27, 2019 11:54 pm

user1234 wrote:
Tue Aug 27, 2019 10:11 pm
There are more reasons why i do that.

1. That is common in pretty every commercial CAD System, a kind of habituation for me.
1.1 A drawing depends on a part, both should always be together. So both is fixed together, see --> 2.
Honestly, you should just put them in a Std Group. A Std Part was a new object in FreeCAD 0.17, and it had a very defined objective, that is, to be used as a container for assembly. However, the implementation of Std Part wasn't finished, and no official assembly workbench was developed, so Std Part remained in a kind of odd way. Besides, a Std Part has a local coordinate system, telling you it should be used for placing different solids, not just arbitrary information. A group is just a folder, something to store things however you want, it's much more generic.

Originally I also thought that Std Parts were going to be like Catia parts, and it would all work the same, but then I realized it didn't, so it's best no to think of FreeCAD as a commercial clone and beware of its specific things.
you will get frittered (is tha the right word? German: verzettelt)
LOL. I've never heard of either expression. Maybe the best translation would be to rephrase it with "I just procrastinate or waste a lot of time".
Always add the important information to your posts if you need help.
To support the documentation effort, and code development, your donation is appreciated: paypal.