Ask questions about DataCAD 20, DataCAD LT 20, or previous versions here.
#66744 by Paustin
Wed Jul 01, 2015 1:33 pm
I am getting unacceptable lags / delays while datacad 16 refreshes displays of xrefs or during plot previews.

The problem seems to involve hatch patterns used in xrefs: I typically create elevation sheets consisting of an xref title block, and two xref elevations. If there is a stone hatch used in the elevations, the xrefs can take 30 seconds to 1 minute regenerating on screen (during the refresh while selecting or editing) and Plot previews can take in excess of 3 minutes. Batch plotting does not help very much - plot times are more than 3 minutes per file.

I am not sure, but this seems to be getting worse over time, or my patience is wearing thin.

Is this just because of the complexity of the hatch patterns? If so, this is unacceptable, as we have performed comparison tests translating the files to autocad, and the screen display regens are almost instant, and plots take 10 seconds. IMHO, Datacad's graphics engine is now probably too old, and is not performing adequately (?).

System:
Dell XPS
intel(R) Core(TM) i7-4770 CPU @ 3.40GHz 3.40 GHz
Ram 12.0 GB
NVIDIA GeForce GTX 645
Windows 8.1 64-bit
Last edited by Paustin on Thu Jul 02, 2015 10:01 am, edited 1 time in total.
#66746 by Paustin
Wed Jul 01, 2015 8:40 pm
Yes. The references are clipped. We typically draw all the elevations aligned in a reference drawing, then compose them on a plot sheet (using xclips).
We see a significant lag every time the program needs to refresh the xref, for example: identifying the reference or right-clicking to open the xref menu, or while selecting the reference to change the clip cube, and the same delay happens each time you escape from one of these functions, and the reference renders again.

We design custom homes and require a high level of detail in the elevations, sections and interior elevations, so there is a fair amount of hatches and fills that we need to use. Is there a recommended or optimal way of handling references that might improve the display performance?

Thanks for the quick reply; I would appreciate any insight you could provide.
Last edited by Paustin on Thu Jul 02, 2015 10:09 am, edited 1 time in total.
#66747 by Paul Nida
Wed Jul 01, 2015 9:43 pm
We have had the same problem for some time. Some hatch patterns are worse than others. Just working on the drawings can get very slow whether there are any clip cubes or not. It seems to be getting worse not better.
#66748 by MtnArch
Wed Jul 01, 2015 10:17 pm
I'll have to add my voice to the tempest brewing as well. I'm working on a custom residence that I have (4) hatches (standard roofing (lines), 45deg standard lines, a rock hatch (from CheapTricks) and one SPB fill on all 4 elevations. It is incredibly slow - even in the original non-xref'd/non-xclip'd file; the files that they are xref'd/clip'd into are even worse. I've used the same hatching on other projects for this contractor and don't remember it being this bad.
#66750 by joshhuggins
Thu Jul 02, 2015 12:11 pm
If you turn Hatch off in the Display menu does it speed up? Wondering if xref nesting could be related.
#66751 by Paustin
Thu Jul 02, 2015 1:17 pm
Yes, turning of display hatch does improve the regeneration of the drawing on screen, so this seems primarily related to hatch patterns. It is also generally necessary to leave display hatch turned on in the plot drawings to 1: visually verify the drawing is complete before plotting, and 2: plot the hatches.

There are no nested references, so I think this should not be an issue. (Our floor plans are created with some nested references, but they do not lag as much. And since nesting is a program preference, and not drawing-specific, we leave it turned on, to avoid the extra task of turning it on and off each time we switch drawings).

I have also worked for years with drawings larger and more complex than the ones I am currently referring to (and operating on larger shared networks), and I can't remember having this much lag (I hope I am missing something...)

My larger concern is a feeling I have that this should not even be an issue with the speed of current processors and graphics cards. We interact all the time with programs that calculate and render images and objects far more complicated than a 2-D drawing, and do so much faster. Expectations of performance continue to increase, and programs need to keep pace.
#66752 by Paul Nida
Thu Jul 02, 2015 1:41 pm
Yes, turning off the display of hatch will speed up the drawings while you are working on them. But it can make it harder to edit the materials they represent. Also it doesn't help with batch plotting.
#66753 by joshhuggins
Thu Jul 02, 2015 1:57 pm
I wasn't meaning to turn the hatch off as a solution to the slowness, but to verify if it was indeed the hatch causing all the slowness vs. something else.
#66754 by Mark F. Madura
Thu Jul 02, 2015 2:36 pm
There are a few things to consider regarding the display performance of hatch patterns displayed within XClips.

Certainly, the more complex and dense a hatch pattern is, the more vectors it will contain, and the longer it will take to display.

Inherently, hatch patterns are first clipped within their own boundaries.

When they are contained within a clipped XREF, they need to be clipped again.

Every vector in the XREF needs to be evaluated as to whether or not it lies outside of the clip boundary and should be rejected.

All the vectors determined to cross the boundary need to be clipped.

I recently evaluated a drawing where all four densely-hatched elevations were being referenced in from the same layer four times, each with it's own corresponding clip boundary to isolate one from the other three.

This is the least efficient way to set this up, as every non-displayed (i.e., outside the clip) elevation bogs down the pipeline. Each elevation should be on it's own layer (or set of layers), then referenced, without a clip boundary if possible.

So consider that every entity that lies outside of the XClip will affect performance.

The other scenario we see in 'slow' drawings is a lot of self-references in a drawing with a large number of layers. Since DataCAD needs to determine which layers in each XREF are either on or off, self-referencing a drawing with 100 layers, 100 times will create 10,000 layers for DataCAD to query. If the self-references only contain a few layers, then the remaining 97 layers are just bogging the drawing down. So where possible, keep references that contain a lot of layers to a minimum.

There are certainly other elements that can slow down a drawing, but these are the two main bottlenecks we see.

We will be looking into what enhancements we might be able to make to speed things up in this area. In the meantime, you may have to consider some organizational changes to the way your drawings are set up.

If you'd like us to evaluate your file, please send a message to help@datacad.com.

Thank You,
#66755 by Roger D
Fri Jul 03, 2015 8:07 am
A few other items that might help during drawng and will not effect the plotting
7) Added the following new keys to the [Printer] section of dcadwin.ini:

[Printer]
Print Text=DEFAULT
Print Hatch=DEFAULT
Print Line Weight=DEFAULT
Print Line Types=DEFAULT
Print Associative Dimensions=DEFAULT
Print Fills= DEFAULT
Print Bitmaps=DEFAULT
Print KnockOuts=DEFAULT
Print Smart Wall Hatch=DEFAULT
Print Smart Wall Fill=DEFAULT

Set any of the above to TRUE to force them to print, even if the attribute setting in the Utility/Display menu is turned off. If set to DEFAULT or missing, the drawing's display toggles T, H, L, U, D, F, B, and K in SWOTHLUDFBK will be used to determine whether or not the attribute is included in the printed output.

8) Enhanced speed of display (up to 2x times faster) when switching between GoTo Views or regenerating the screen. There is dcadwin.ini key to disable this new feature:

[General]
New Smart Object Generation=FALSE
When absent or TRUE (default), DataCAD uses the new faster method of screen regeneration. When FALSE, the older method is used.
#66756 by Paul Nida
Fri Jul 03, 2015 8:54 am
Yes Roger, that does help with drawing and I've been using it since it was implemented. But it doesn't help with plotting speed and we often have to have display turned on to work on them. The funny thing is, we have been using the same hatches in the same way for many years and it seems to be getting slower all the time.
#66757 by Roger D
Fri Jul 03, 2015 9:04 am
I've been finding similar, esp. with heavy use of xclips on self-xref's where using 1 self-xref for multiple GTV/Plot Details.
But still faster than the old P5 chips with the DOS memory limits of 624(?).
#66758 by Paul Nida
Fri Jul 03, 2015 12:31 pm
No doubt the computers today are much faster and the software is way better and more sophisticated. I remember plotting very complex 30x42 sheets of drawings that took over an hour to plot. You just had to wait and find something else to do during that time. And god forbid you found a mistake when it was finally plotted. Often if the error wasn't too bad the electric eraser and rapidograph pens would come out. Now we have been spoiled and a 2 or 3 minute wait is unbearable. Plus I'm getting older, crankier and I have a lot less patience than I did then.

Who is online

Users browsing this forum: No registered users and 37 guests

About DataCAD Forum

The DataCAD Forum is a FREE online community we provide to enhance your experience with DataCAD.

We hope you'll visit often to get answers, share ideas, and interact with other DataCAD users around the world.

DataCAD

Software for Architects Since 1984