Hi,
I have two copies of QCAD 3.22.0.0 (3.22.0)
One works under 10.14 Mojave on Macbook 13 pro (i5 proc)
Second is under Win10home (with quad-core i7 and 8gb)
I've recently opened some .dwg project on both comps. There are a lot of layers and objects. Works VERY slow on both notebooks.
Then I saved .dwg to .dxf hope it would be faster when works in native format. Nothing better.
My macbook is not fast but PC is quote OK (quite old but CPU is still not bad).
How can I increase the speed?
QCAD works rather slow
Moderator: andrew
Forum rules
Always indicate your operating system and QCAD version.
Attach drawing files and screenshots.
Post one question per topic.
Always indicate your operating system and QCAD version.
Attach drawing files and screenshots.
Post one question per topic.
Re: QCAD works rather slow
Hi,
But .... if there is really no other way around that don't use the arrangement two or three times in the same drawing. Split it to three drawings.
I would recommend to simplify the plant blocks. Yes, I agree - it looks beautiful but that is a design which has to be done in a graphic program and not in a CAD program.
But .... if there is really no other way around that don't use the arrangement two or three times in the same drawing. Split it to three drawings.
Work smart, not hard: QCad Pro
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Win10/64, QcadPro, QcadCam version: Current.
If a thread is considered as "solved" please change the title of the first post to "[solved] Title..."
Re: QCAD works rather slow
Thank you for your reply!Husky wrote: ↑Thu Apr 22, 2021 7:07 pmI would recommend to simplify the plant blocks. Yes, I agree - it looks beautiful but that is a design which has to be done in a graphic program and not in a CAD program.
But .... if there is really no other way around that don't use the arrangement two or three times in the same drawing. Split it to three drawings.
In fact the plan firstly created by me in QCAD. I prefer to add any 'sections' (like electric lines or waterpipes eg.) into one project.
Because when you split it to several parts it loose 'consistency' next day or week.
We recently gave our plan to landscape designer and she has real sizes etc. Then she has made the work, added some layers and returned the whole project. Of course I will hide the layers which is not useful and try to simplify drawings.
But I think that CAD has to work even with big projects. What resources actually needed? Mac Pro? )) Maybe you know what OS works better (faster)?
What file format is better in such case: convert dwg to \native' dxf or to continue working in dwg? Maybe there are another hints and tricks?
Re: QCAD works rather slow
Hello,
Don't be discouraged...
It doesn't seem that the plants are the major problem.
Although, there are minor issues with them.
First I turned off the blocks with the plants what reduced the lagging only a bit.
Then turned them all back on and isolated the hatches what seems to work far better.
OFF-ON took about 20 minutes or so.
The Hatch engine has a hard time in rendering your hatches.
A) The general advise with QCAD is to keep your hatch origin near the hatched area.
'Near' would be in the order of 0-20.000 units, the drawing extends up to 210.000 units!
In fact, it is 'tile' & 'tessellation' based, what doesn't tell most of the users anything.
To put a hard number on it, the tile size, the scale and the unit matter.
Solid or simple hatch patterns don't really care, harder are AR-CONC & GRAVEL for example.
With the same layout at two distinct places, hatch origins should match the actual position.
The idea of layers is that you can put different things on different layers over each other.
Here there are 3 distinct and unrelated copies, about 100.000 units spaced.
B) There is an issue with hatches in blocks. I still can't put my finger on it.
Even if the hatch origin is near at Block level, it may not be near at Model level.
The hardest then are scaled references, here not really used.
Those may trow in huge lags. Hatching may time out while the end scale is nothing else as 'normal'.
Some plants use pattern hatching. If solid is an option, I would change that.
Have a look at the isolation report: There are 270 individual hatch contour loops involved.
Some of those loops are in Blocks and need to be rendered N times.
Some boundary lines are overkill like entity 0x2ee1 or 0x2dfe (Type TH + handle to select one)
There are a few more of those.
Some contours are even weird like the one of hatch 0xa2df (In revision on Layer0/HatchEntities)
Parts of the car are hatched.
I would use one rectangular (=easy) hatch + the solid hatch of the car outline + car entities and set an order to stack.
About the plants:
*U17 uses *U16 (block in block)
*U18 = *U16, *U19 uses *U18
*U20 = *U16, *U21 uses *U20
*U22 = *U16, *U23 uses *U22
*U24 = *U16, *U25 uses *U24
*U26 = *U16, *U27 uses *U26
Maybe you could streamline that better.
There are some redundant lines in this plant symbol.
Anything less is N times less.
A$C76723A97 uses z_05
Also a block in block construction
The last four plant blocks with names I can't include, are identical in shape and use spline entities.
Turned off, the general lag reduces even more.
Seems that splines have quite a workload and that M times N times.
Maybe faster as Polylines or as individual Arcs-Lines.
Revision included: Regards,
CVH
Don't be discouraged...
It doesn't seem that the plants are the major problem.
Although, there are minor issues with them.
First I turned off the blocks with the plants what reduced the lagging only a bit.
Then turned them all back on and isolated the hatches what seems to work far better.
OFF-ON took about 20 minutes or so.
The Hatch engine has a hard time in rendering your hatches.
A) The general advise with QCAD is to keep your hatch origin near the hatched area.
'Near' would be in the order of 0-20.000 units, the drawing extends up to 210.000 units!
In fact, it is 'tile' & 'tessellation' based, what doesn't tell most of the users anything.
To put a hard number on it, the tile size, the scale and the unit matter.
Solid or simple hatch patterns don't really care, harder are AR-CONC & GRAVEL for example.
With the same layout at two distinct places, hatch origins should match the actual position.
The idea of layers is that you can put different things on different layers over each other.
Here there are 3 distinct and unrelated copies, about 100.000 units spaced.
B) There is an issue with hatches in blocks. I still can't put my finger on it.
Even if the hatch origin is near at Block level, it may not be near at Model level.
The hardest then are scaled references, here not really used.
Those may trow in huge lags. Hatching may time out while the end scale is nothing else as 'normal'.
Some plants use pattern hatching. If solid is an option, I would change that.
Have a look at the isolation report: There are 270 individual hatch contour loops involved.
Some of those loops are in Blocks and need to be rendered N times.
Some boundary lines are overkill like entity 0x2ee1 or 0x2dfe (Type TH + handle to select one)
There are a few more of those.
Some contours are even weird like the one of hatch 0xa2df (In revision on Layer0/HatchEntities)
Parts of the car are hatched.
I would use one rectangular (=easy) hatch + the solid hatch of the car outline + car entities and set an order to stack.
About the plants:
*U17 uses *U16 (block in block)
*U18 = *U16, *U19 uses *U18
*U20 = *U16, *U21 uses *U20
*U22 = *U16, *U23 uses *U22
*U24 = *U16, *U25 uses *U24
*U26 = *U16, *U27 uses *U26
Maybe you could streamline that better.
There are some redundant lines in this plant symbol.
Anything less is N times less.
A$C76723A97 uses z_05
Also a block in block construction
The last four plant blocks with names I can't include, are identical in shape and use spline entities.
Turned off, the general lag reduces even more.
Seems that splines have quite a workload and that M times N times.
Maybe faster as Polylines or as individual Arcs-Lines.
Revision included: Regards,
CVH
Last edited by CVH on Fri Apr 23, 2021 4:52 am, edited 2 times in total.
Re: QCAD works rather slow
https://qcad.org/rsforum/viewtopic.php? ... ble#p29817
Doesn't matter ... A dwg is stored as dxf with AutoSave.
A dwg is binary and smaller as file, a dxf is ASCII.
Both will have the same amount of entities = EMCASript objects.
Really happy with my old Win7 HDD 4Mbyte first generation i7 pentium, and the 32bit usually give me an edge over 64bit users.
The revision loads in 10 seconds, fps about 3 @ zoomAll, fps = normal zoomed in, works for me.
Regards,
CVH
Last edited by CVH on Fri Apr 23, 2021 8:52 am, edited 1 time in total.
Re: QCAD works rather slow
Great work, thank you!
I've recently saw that QCAD had been written on Qt. So I think should not be slow due to poor environment.
Also I see that initially our designer draw she's part of plan in ArchiCAD and then exported to 'non-native' dwg. Of course it is far from optimal. Not sure that it is possible to have dwg/dxf from there another way. But who knows?..
I will keep original landscape with every leaf and try to reduce/redraw/simplify into more schematic version for real work.
BTW what can people say about new Macs with M1 CPU? Are they really faster than previous? I see that my current macbook pro (mid 2012) has to be upgraded in nearest future...
I've recently saw that QCAD had been written on Qt. So I think should not be slow due to poor environment.
Also I see that initially our designer draw she's part of plan in ArchiCAD and then exported to 'non-native' dwg. Of course it is far from optimal. Not sure that it is possible to have dwg/dxf from there another way. But who knows?..
I will keep original landscape with every leaf and try to reduce/redraw/simplify into more schematic version for real work.
BTW what can people say about new Macs with M1 CPU? Are they really faster than previous? I see that my current macbook pro (mid 2012) has to be upgraded in nearest future...