What Causes QCAD To Slow Down

[Husky]

So far, we have learnt two type of "patches" to this bug with this hatches (I believe that we must call it bug...)

Please feel free to file a bug report below: https://www.qcad.org/bugtracker
Thank you!

[CVH]

I believe that we must call it bug...

Giuliano69,
I am rather certain that it is not a bug ...
... For now I can only agree on that rendering of hatches is not optimized.
All due to how QCAD handles hatching or basically any entity.

Let's say I know the most there is to know on hatching patterns.

I developed an addon that can create a hatch pattern of anything in a right quadrilateral called a 'tile'.
Very advanced hatch patterns are possible, pattern coding works flawless and John Hyslop has used Tile2Hatch with success.
The downside is that the generated patterns may quickly exceed QCAD capabilities rendering the tool useless.
I am also the writer of the code in BHT that can create herringbone patterns with fractional ratios.
Something that is believed to be impossible up to now.
Even non-equal boards with non-equal ratios not necessarily being integers are possible.
True, there are limits to both methods, in general, limits due to the floating point representation of numbers.

So far, we have learnt two type of "patches"

You missed breaking up the HONEY hatch in 12 individual hatches.
Besides the proposal by Husky to remove it from the block and place it directly on model space.

Isolating hatches on a dedicated layer and locking that layer is the most logical step.
All considering the general design rule that layers should control attributes:
https://www.ribbonsoft.com/en/tutorial- ... ith-layers.

... you DO NOT know which hatch will cause a bug in QCAD.
And you will loose time finding the "bad guy" and fix it in some way...

True, and an easy fix would be a proposal script that isolates all hatches included in a drawing.
Whiting a few clicks I was able to find the culprit.
It would indeed be harder with hundreds or more hatch entities.
I have more such custom written scripts at hand and they get smarter on every problem encountered.

Please consider also that that hatch has caused no such problem on the other program that created the drawing ...

One can't be sure of that or the latency wasn't noticeable ... or not noticed.
What you don't consider here is the price tag.

Bottom line:
- I construct my hatches from perfectly closed boundaries that I create/copy/isolate on a dedicated (sub-)layer.
- My hatches are always on what are also dedicated (sub-)layers.
- Beside on creation/adding hatches these layers are mostly locked and can be hidden individually when needed.

And finally, as CNC engraver, I mostly have no use for hatches at all.
In the end, my production file will only include hatches exploded to line entities.

But I'll be looking further into 'the surrounding hatch in a block' thing more closely the coming weeks for sure.
Just out of interest for Tile2Hatch.

Regards,
CVH

[Giuliano69]

Thanks CVH for your reply.

I would like to add some more considerations on the .... INABIAF

-Net3 shows the same problem. So it is not a bug in THAT specific honey hatch
-When double clicking and editing the hatched block ONLY, with the honey hatch, the zoom is very fast. So it is not the geometry of that specific hatch that create the problem. That hatch CAN be drawn and zoomed very fast by the program.
-If the mouse is OVER the hatch or just INSIDE the hatched area, the drawing zoom procedure get stuck. If it is OUTSIDE the drawing zoom procedure is normally fast. So it is not an CPU/“horse power” problem, but an algorithm problem,getting stuck in some situation that need investigation ...
-in other words it is a bug ... sorry a feature


For the younger user that may be too young to know the INABIAF history
https://www.wired.com/story/its-not-a-b ... a-feature/

Giuliano

[CVH]

-Net3 shows the same problem. So it is not a bug in THAT specific honey hatch

HONEY.pat has a cloning load of 6, NET3.pat is even less with a load of 3.
So, no it is not the pattern itself, it gets troublesome with a cloning load of 60 or more.
Send me a PM for more information on this.

Using GRAVEL instead of HONEY the zoom latency when pointing inside the building will increase at least tenfold.
Simply by the larger cloning load of the original GRAVEL pattern.

When double clicking and editing the hatched block ONLY, with the honey hatch, the zoom is very fast.

Correct, QCAD doesn't have to determine if you are pointing at a block with a hatch in it.
It is again just the same with the HONEY hatch in a block in block construction.

... but an algorithm problem, getting stuck in some situation that need investigation ...

Can be, that needs some more investigation. It can also be the way things are, a compromise.
Intriguing here is the 12 hatch remediation.
Then the latency is only somewhat higher in the corners of the building ...
... Inside the box arround the L-shaped hatched areas.

Regards,
CVH