Performance with hatches and layout blocks

[cccplex]

Hi, I have a performance issue with hatches. Apparently more user notice problems with hatches: https://qcad.org/rsforum/viewtopic.php? ... =15#p26976 But it might be that the layout blocks are the culprit.

I feel that there is something that can be done here. Of course not based on any technical knowledge. I already made a bugreport some weeks ago. https://www.ribbonsoft.com/bugtracker/i ... sk_id=2063 I think there could be more reports about performance issues. Can we maybe pinpoint / disect some individual problems here that can be solved?

The thing I noticed is the differences in performance while zooming with hatches on. When using the mouse for zoom inside a layout block almost nothing happens. But using + - on the keyboard does perform. Or is having a central reference point that much easier for the renderer? Also when the mouse pointer is outside the layout the zooming is performing normal. But after a while this problem is also happening with my hatches layer off. So maybe the layout block is the problem here.

Anyone having some ideas?

[CVH]

Hi,
Seen the bugreport.
And as I said in the other reference:
It is quite hard to put your finger on when and what.
Still buzzing ... got a tool to create patterns from entities in the pipeline.

I speak from experience, made many hundred hatches, large ones, complex patterns and with huge offsets or spans.
At a certain point you stop with putting more in one and the same dxf because of the lagging.
Or run dozens of tests with one single squared-out boundary and one hatch pattern and hope it doesn't time out.

The case you present is one of the category 'Focusing'.
Moving the cursor over a drawing or zooming with the mouse-wheel are both mouse actions.
Using + / - on the keyboard is that not.
Try both together what is hard to evaluate.
Try pointing inside and lift your mouse when zooming with the mouse-wheel.

Qcad constantly updates the focus to the nearest entity on mouse actions.

Solid hatches get the focus when you sit inside the boundary and no other entity is in the vicinity.
Patterned hatches get the focus when you are near one of the hatch segments.
In doing so, one can select entities covered by a hatch as long as you know exact where to point at.
Patterned have also a reference point where an individual line segment touches an entity at the boundary.
I can't come up with a pratical use for them.

That are a vast amount of evaluations to be made just to figure out if any counts as focus.
Viewports add another layer of: am I ... or am I not focused? But then focusing as one whole.
And it seems that even when locking the layer(s) with the hatches, hatch segments are evaluated in viewports.
Focusing or not is changing the displayed color.
That of the viewport, with all its hatches, with all their line segments ...

The lagging is the computational effort to evaluate all this and set or clear the focus.
The math is extremely fast, the problem is the quantity.

A solution in your case could be locking layer 'A--L$3A__V-ports'.
Then mouse zooming acts the same as if you where pointing in the void.
But you figured that out yourself. (Bugreport)

This is not the end of the story:
-Size - Position - Complexity
-Selected - Selection changes
-Moving - Pasting and their preview
But also layer manipulations and their properties.
Even hiding or frezing a layer with a laggy hatch!?

Or is having a central reference point that much easier for the renderer?

Yes, about always ... It's less effort and still pretty accurate.
https://qcad.org/rsforum/viewtopic.php?f=30&t=6887
Halfway the first page ... (Read all if you like).
In the file dXshift Fix.dxf one can see how segment 101 is rendered in:
- the neigbouring 'Tile' ->35th clone & 34th repetition
- an equal tile at position (10000,10000) ->710000th clone & 690286th repetition

Central, No, if you don't want the hatches with the same pattern to shift regarding the others.

Keep it near, that is the message.

Regards,
CVH

[cccplex]

It is a bit difficult to grasp. But reading your reply again today and some notes of mine i wonder if some toggles can be implemented to decrease the lag in the above situations.

For instance one that switches of the focus of all the things in a hatch and only keep the handles of the polyline that surrounds it. I often have a situation where I want to edit lines and hatches together so locking layers is not an option then. What I do now is lock or hide the hatch layer, edit the lines and then make the hatches active again to move them to the same spot.

What also bothers me is, what you describe above I think, Is the intersections of the hatch patterns with the rest of the lines. They mess with my snapping. Often I find out my lines don't line up because I snapped to the hatch in stead of the corner. I think, a toggle to turn those intersections off can be a feature request right?

Also the rendering of a difficult hatch is a real pain when you want to edit that hatch. For instance the gravel. If I want to move a corner I get a fps of around 2. Maybe a toggle to turn of the rendering while modifying the hatch can help here. Turn off the hatch while modifying it and reapply after finished.

I really like to see my hatches while drafting so I hope there is some workaround possible here. We don't need to work with the insides of the hatch, only with the border and keep focusing, snapping and rendering to a minimum.

[andrew]

Please indicate your QCAD version and OS, I cannot reproduce that behavior here (snapping to the pattern lines of a hatch).

[CVH]

For instance one that switches of the focus of all the things in a hatch and only keep the handles of the polyline that surrounds it.

YEP (!not restricted to a Poly)

Is the intersections of the hatch patterns with the rest of the lines. They mess with my snapping.
...
I think, a toggle to turn those intersections off can be a feature request right?

YEP To reconsider after a 'pratical use' is presented.

Turn off the hatch while modifying it and reapply after finished.

YEP, no preview of hatch patterns, only preview the boundary.
Or preview when 'steady' ...

For instance the gravel.

NOOP, not really a complex pattern, I can assure you that.
Try out patterns with several thousands of line definition entries

I really like to see my hatches while drafting

Your problem was lag in a layout !?
While drafting in model space the work around is 'Locking' the hatch layer.

What I do now is lock or hide ...

And that is how you do it ...

We don't need to work with the insides of the hatch, only with the border

NOOP, it might become harder / impossible to select a hatch only by the boundary.
Except using more tricks.

I still suspect a bottleneck in the hatch rendering engine ... pure math.
Reading : "The process of hatching consists of ..."
way down in : https://knowledge.autodesk.com/support/ ... E-htm.html

I really hope this is not implemented literally as stated !!!
That would be a major flaw that sets a huge restriction on the usability of Tile2Hatch.
Or any somewhat more complex pattern.
Even 'gravel.pat' rather far or with larger spans / smaller scale.

Problems with Hatch patterns can be tackled in 4 ways:
- User work around (limited)
- Render Props
- Render Math
- Rigorous pattern coding

For the latter I am developing Tile2Hatch with success.
As long as Qcads renders it or doesn't time out of course.

A partially new pattern, cutting down in complexity, is made in seconds.
Moving it in the OS portion in windows in the correct formatting,
reboot, reload, redraw and not to mention the LAG they may induce ...
...takes 100 times longer.

In the way you pick up some habits, tricks and other things to make it workable ...

Please indicate your QCAD

Latest full release QCAD 3.24.3

Regards,
CVH

[CVH]

(snapping to the pattern lines of a hatch).

In the attachment:
Entities on Layer 1 are drew snapping to 'Boundary' and 'Hatch'.
After Hiding/freezing the Layer 'Boundary'.
One still can snap to the blues intersecting the Hatch.
Identical as for 'Boundary' intersecting the Hatch.
But not on the edge of the Hatch without intersection!
With the Layer 'Boundary' 'on' there are a lot of snappers to consider ...

Regards,
CVH

[andrew]

Thanks for the details.

Bug report at:
https://www.qcad.org/bugtracker/index.p ... sk_id=2090

[CVH]

Patterned have also a reference point where an individual line segment touches an entity at the boundary.
I can't come up with a pratical use for them.

So, this was unintended behavior !!
CVH

[cccplex]

Please indicate your QCAD version and OS, I cannot reproduce that behavior here (snapping to the pattern lines of a hatch).

I also use the latest QCAD 3.24.3.0 and have put my hardware specs in my signature. I'm glad we could pinpoint a bug.

As for:

Your problem was lag in a layout !?
While drafting in model space the work around is 'Locking' the hatch layer.

I have a box with a gravel hatch in model space. Whenever I want to modify it by stretching, moving or using the handles I get lag issues. (around 1 to 2 fps if I must estimate) So what I do is turn the hatch layer off and modify the polyline that has the same border as the hatch. That way I can precisely modify without lag. Then I turn on the hatch and move the hatch boundary to the polyline.

gravel-lag.dxf

(107 KiB) Downloaded 85 times

NOOP, it might become harder / impossible to select a hatch only by the boundary.
Except using more tricks.

I use alt click to select entities most of the time. I have no issue with finding the border of a hatch and alt clicking to select.

[cccplex]

Focusing or not is changing the displayed color.
That of the viewport, with all its hatches, with all their line segments ...

I found a toggle in the settings: graphics view -> behaviour -> highlight entity within range
I'm glad to have found this because I don't need the distraction of highlighting things when I move the mouse. Although I didn't notice any difference in lag.

[CVH]

I have a box with a gravel hatch in model space. Whenever I want to modify it by stretching, moving or using the handles I get lag issues.

The topic is 'Hatches and Layout blocks'.
The lag you experience with modifying the boundary in model space is a 'Preview' issue.
It takes that long to render all the individuals from the pattern.
(Best seen with a continuous motion of the mouse)

This boils down to complexity and hatching engine math.
Complexity:
With 'gravel.pat' the 41 Line-segments every Tile isn't that of an issue ...
About 68.35 tiles of 25.4x25.4 can't be called a large hatch...
The segment hardest to render would be 222.3974°, inline repetition ~791 and endless cloned in parallel 0.8155... apart.
Most of the necessary ~1110 clones to cover your Hatch won't even have a segment in your narrow hatching area.

You'll find them exploded to only 98 Line-segments having 267.3974° as angle. ( 222.3974+45)
-> Selection Filter: Line, Angle, isEqual ... Replace selection.
You can visualize the used clones by setting the segments Specific Property Length to 300 or so.
98 out of ~1110 useful for only one of 41 entries in the pattern file.
You really don't want to know how many shifttings that where applied in that process.

What I discovered only recently is the fact that the Hatching property 'Angle' alters complexity.
With your original file: Zoom in @0;-120, have a good look at the pebbles and then zoom in @500;-120.
A pattern that looses coherency about 20 tiles away from its origin is coded very badly or is rather complex.
The standard pattern 'gravel.pat' is coded too lean but not super complex. The induced Angle alters this.
With Angle = 0 the fps is bit better than 2 but not to be called a major improvement.

Hatching engine math:
Besides that the hatching math will choke at some point.
Besides metric, with larger values, has the odds against.
I really do hope that a Hatch is NOT an inner-join of a hatched plane and an area enclosed by the boundary!
Or with 'gravel.pat': An inner-join with 41 hatched planes ... with each thousands of clones ...

I really don't know, I have no insight in the hatching engine.
I am only recording behavior and try to grasp the how, the why.
Hopfully this will lead to less effort, less lag and coherent hatching.
It has already led to rigorous pattern coding.

Regards,
CVH

[CVH]

I found a toggle in the settings: graphics view -> behaviour -> highlight entity within range

I suspect that evaluating hasFocus is still necessary and only the highlight is suppressed.

CVH

[cccplex]

What I discovered only recently is the fact that the Hatching property 'Angle' alters complexity.
With your original file: Zoom in @0;-120, have a good look at the pebbles and then zoom in @500;-120.
A pattern that looses coherency about 20 tiles away from its origin is coded very badly or is rather complex.
The standard pattern 'gravel.pat' is coded too lean but not super complex. The induced Angle alters this.
With Angle = 0 the fps is bit better than 2 but not to be called a major improvement.

Thanks for the heads-up. I changed my gravel hatches now to gravel-01 by John Hyslop and use the angle of 0.
I also found a workaround that is workable for me. When i toggle the gravel hatch to solid I can modify it without lag. Then when I toggle it back the values of the pattern hatch come back and the hatch is rendered to its new position.

[CVH]

gravel-01 by John Hyslop

Much more stable but Prior Art.

When i toggle the gravel hatch to solid I can modify it without lag.

A solution for selects, mods and moves but not for copy, paste, save, load ...
CVH

[cccplex]

A solution for selects, mods and moves but not for copy, paste, save, load ...

Copy and paste works. Inside and between files. Save load indeed not.
Ah, after some more testing: Apparently it doesn't work for all patterns.
This simple one I use does not come back after toggle solid back and forth.

Code: Select all

*HPZG60N1,Free patterns from www.AUTOCADhatch.com
60, 0,0,	0.5774,-1.0000,	1.1547,-1.1547 
120, 0,0,	0.5774,1.0000,	1.1547,-1.1547