Jump to content
  • 11

Top/plan panning/zooming sluggish in VW2018


line-weight

Question

One of 2017's selling points was a new graphics module which was to make viewing large 2d drawings smoother and faster. I think it did.

 

But I'm finding that this has gone in 2018. Zooming in and out is slow and jerky, like it's really struggling with the file size.

 

If I try opening the same file in 2017 it's noticeably better.

 

Are others finding the same?

  • Like 1
Link to comment

Recommended Posts

  • 0

A like for JimW, as usual.

 

A big dislike for VW's commercial decision to release the software even though it's clear there are these problems with it.

 

I think there is a "single issue" causing it: insufficient testing.

 

It's why I made a wishlist item last year for VW2018 to have no new features, and have energy focussed on making everything that's already there work properly. I think I'll do the same for VW2019.

Link to comment
  • 0
7 hours ago, Art V said:

the issue is worse in VW2018  with drawings started in VW versions before VW0217 and less worse with drawings started in VW 2017 or VW 2018

 

I think I don't have any VW 2018 started project.

But for me the worst experience was a VW 2017 project started just a few months before VW 2018 release.

Not so with pre-VW 2017 projects (which maybe did use more Solids only though)

 

But for me it feels like VW 2018 has larger impact to data and geometry over previous release

than ever before. When Windows Styles came in VW 2017 I hadn't seen any problems converting

my old Windows to Styles. With VW 2018 everything migrated seemed problematic.

Like PIOs, Styles; Resources, everything.

Looked like you could not trust these at all until finally manually editing these in VW 2018 which

helped in many cases.

And vice versa, it looks like most PIOs aren't editable again wenn converted back to a previous

version. Something I can't remember from the past.

So I hope, after so many changes, PIOs are much better now :) 

 

Overall, as I do no 2D title border drawing label stuff, VW 2018 works ok for me.

Link to comment
  • 0
45 minutes ago, line-weight said:

It's why I made a wishlist item last year for VW2018 to have no new features, and have energy focussed on making everything that's already there work properly. I think I'll do the same for VW2019.

 

I did this in 2015 after my first release upgrade and it didn't help either :)

Link to comment
  • 0

@JimW In your hardware recommendations article you mention two things that caught my attention:

 

"Your Processor, or CPU directly affects how long a Renderworks rendering will take in Vectorworks. It also affects the speed at which geometry and movement calculations are completed."

"(The CPU speed does NOT affect the speed of Top/Plan or OpenGL, these are dependant on the GPU.) "

(For reference for others, the article link is below)

 

One of the things local support and I noticed was that in TOP/Plan the GPU didn't seem to get used at all when moving items, and which is where I experience the excruciating slowness when moving just one simple item. Based on your comments above one would expect the GPU to be used when moving items.


Now, I did the Cinebench tests for GPU OPenGL, CPU multicore and CPU single core and much to my surprise the results were decent compared to a same generation i7. A same generation i7 at 4.4 Ghz with 4 real cores and 4 virtual cores was only approx. 50% faster than my 3.5 Ghz i5 with only 4 real cores in the multicore CPU test and in single core the difference is marginal, so it seems to me that either it is not the processor if VW2016 is much faster for the same operations than VW2018, or VW2018 needs much more power and would require the latest generation CPU's. The GPU seems to be more than capable for 2D operations. Unless the results are according to you such that it would be enough reason to look for a more powerful (CPU) system.

 

Could it be that there is an issue with the communications with nVidia graphics cards if the GPU is not used? Is there some way to test this in a repeatable manner for VW2018 vs VW2016? As @Kevin McAllistermentioned some standardized test files might be useful to get at the bottom of this as it could give some idea if some specific configurations are more affected than others.

Cinebench test results for my desktop system are attached.

 

GPU OpenGL performance test.png

CPU Multicore performance test.png

CPU single core performance test.png

Link to comment
  • 0
  • Vectorworks, Inc Employee
On 1/13/2018 at 1:21 PM, Art V said:

One of the things local support and I noticed was that in TOP/Plan the GPU didn't seem to get used at all when moving items, and which is where I experience the excruciating slowness when moving just one simple item. Based on your comments above one would expect the GPU to be used when moving items.

 


Moving your camera around in top/plan, zooming panning etc is GPU based. The moving of objects regardless of what view they are in, is first calculated by the CPU and then displayed by the GPU, but the GPUs portion of that action time is so small it's almost unnoticeable.

Link to comment
  • 0
12 minutes ago, JimW said:


Moving your camera around in top/plan, zooming panning etc is GPU based. The moving of objects regardless of what view they are in, is first calculated by the CPU and then displayed by the GPU, but the GPUs portion of that action time is so small it's almost unnoticeable.

@JimWthanks for the clarification, that explains why the GPU was hardly used when moving an entire drawing over a distance of 500km (in VW, not real world ;))
If I remember correctly, moving objects is still a single core operation so an i7 would not have been that much faster nor would a faster GPU be of much help.

 

Ouch, that hurts quite a bit given the speed difference between VW2016 (instant) and VW2018 (slow or very slow), so I guess I'll have to have patience and wait for the VW2018 lag and other speed issues to get solved.

Link to comment
  • 0
  • Vectorworks, Inc Employee
Just now, Art V said:

Ouch, that hurts quite a bit given the speed difference between VW2016 (instant) and VW2018 (slow or very slow), so I guess I'll have to have patience and wait for the VW2018 lag and other speed issues to get solved.


You may have stated this earlier and if so I apologize, but do you see the same speed delay if you switch to "Best Compatibility" under Tools > Options > Vectorworks Preferences > Display > Navigation Graphics? 

Link to comment
  • 0
24 minutes ago, JimW said:


You may have stated this earlier and if so I apologize, but do you see the same speed delay if you switch to "Best Compatibility" under Tools > Options > Vectorworks Preferences > Display > Navigation Graphics? 

Initially I was at best performance (without realizing it) and with new projects started in VW2018 or even projects started in VW2017 it worked surprisingly well, much better than VW2017 at best performance.
Once I open a project started in a VW version older than VW2017 it became quite slow, and changed to best "Good performance and compatibiliy" which made no difference, and even "Best compatibility " makes no difference.

An example, as I just tested with VW on "Best performance" to get some timings: a simple symbol on a sheet layer consisting of a circle with background colour and a single text field for a number or letter to be used to identify an area in a viewport. The symbols is on the sheet layer on top of the viewport. The viewport crop changed so I have to reposition that symbol.
Selecting the symbol and then drag it to the new location takes 10 seconds before the outline shows up at the new location so that you can see where it ends up, then release the mouse button to actually put the symbol on that new position and then it takes another 16 seconds before the symbol is actually showing up.

 

Total time for moving one instance of this simple symbol: 26 seconds

 

In VW2016 this is instantaneous,: select, move to new position and release to actually place is one fluid operation that is instant. 

 

From a usability perspective the difference is enormous if you multiply this for approx. a dozen symbols that need to be relocated on 5 sheet layers each and you can imagine the frustration/irritation starts to come up quickly as this is not with just this one symbol on a sheet layer but it also happens on design layers etc. 

 

There is at times a very serious lag between selecting an object and the object showing as selected, if you have to select multiple objects and they each have this delay then e.g. selecting 6 objects could take a minute instead of a few seconds. Even worse... because of this lag you are constantly in doubt whether the selection succeeded or not and combined with the lag another select attempt done a fraction too quickly could cause the object to be deselected by accident. This adds up to the actual delay issue.


Unfortunately for this project it is not really an option anymore to revert back to VW2016 due to potential GIS issues that could badly impact the drawing and data if reverting to VW2016.

Edited by Art V
Link to comment
  • 0
13 minutes ago, line-weight said:

All the stuff I've been working on so far with 2018 has involved drawing files which originated in earlier releases. I'm about to start a new project from scratch in 2018 so will be interested to see if I notice any difference with that file, compared to the others.

Please report back when you have progressed far enough with the new drawing for a fair comparison with your pre VW2017 drawings opened in VW2018. It will be interesting to find out if this is a somewhat general difference between drawings started in VW2018 or older drawings opened in VW2018 or "just an anecdotal" difference because it happens to only a few people and not everyone.

Link to comment
  • 0

If I got that right.

 

Most of the typical geometry work in a CAD, opposed to rendering tasks is often

unlikely to be parallelized and divided into multiple threads at all in general.

But there is still some potential for VW do so for these few tasks that could be.

And so multiple CPU cores and hypertheading will not help, even slow down when

multicore CPUs use lower clock speeds and therefore have lower single core speed.

(Not much the case with newer turbo modes)

And that there are other bottlenecks that will even prevent further acceleration by

throwing CPUs with higher single core speeds on it.

So there is a certain but no endless potential of optimizations for modeling and

drawing tasks.

Problems are known but changes will be tedious with complicated dependencies

and larger surgery.

 

For OpenGL, 3D is ok,

2D design Layer speed got larger changes in VW 2017, still has glitches and is still

in the works. Including some hard to find slowing down lags.

Sheet Layer + Viewports have still old slow code, except the new turbo HL for VP

direct editing mode.

 

So for me the most urgent task would be to eliminate these glitches that make

feel VW 2018 slower than 2016 and these new slow downs when changing and

manipulating pre VW 2018 geometry and data.

 

I think even 2D OpenGL quality isn't that bad in VW in general.

More that people are used to throw a lot of line in there view windows.

I can have much more lags with a single simple 2D plan XRef underlay in an

other App.

 

 

Link to comment
  • 0
2 minutes ago, zoomer said:

Most of the typical geometry work in a CAD, opposed to rendering tasks is often

unlikely to be parallelized and divided into multiple threads at all in general.

I agree, but ideally it should not get (much) slower in newer versions of the program.

 

3 minutes ago, zoomer said:

So for me the most urgent task would be to eliminate these glitches that make

feel VW 2018 slower than 2016 and these new slow downs when changing and

manipulating pre VW 2018 geometry and data.

It not just feels slower, it is slower. But I agree with you this is probably one of the issues, if not THE issue,  that have a considerable required urgency to be solved.

Now if only those love buttons would be back as an additional means for upvoting an issue :)

Link to comment
  • 0

@JimWanother question regarding the lag, as I had a pleasant surprise yesterday that I could confirm today.

In design layers there is also a lag when selecting and moving objects, however when I was in a busy area of the drawing I set the layer view to "show others" instead of may default "Show/snap others" and much to my surprise the speed went to up VW2016 levels. This happens in all GPU modes of best performance to best compatibility.

The odd thing is that in "open areas" (few objects)  the lag is also there when the "show/snap others" for layers is active and goes away when set to "show others".
This is independent of snaps set in the Snapping palette.

 

However, on sheet layers the lag stays regardless of layer view setting, but the lag becomes considerably less on the sheet layer if all snaps are disabled reducing it to 8-10 seconds instead of 26 seconds for moving an object as described earlier.

Sooooo..... how is snap working in VW2018 compared to VW2016 where the snap settings don't seem to have this much impact? I get the impression that with "Show/snap others" for layers it snaps to basically everything whether it is visible or not, whether there is something to snap to or not as if the snap range is somehow way too large so that it is calculating snaps to objects that are actually too far away for snapping to. Is that a correct assumption or is there something else going on with snapping and snap settings that could be used to reduce lag if set properly in VW2018?

  • Like 1
Link to comment
  • 0
  • Vectorworks, Inc Employee
7 minutes ago, Art V said:

Sooooo..... how is snap working in VW2018 compared to VW2016 where the snap settings don't seem to have this much impact? I get the impression that with "Show/snap others" for layers it snaps to basically everything whether it is visible or not, whether there is something to snap to or not as if the snap range is somehow way too large so that it is calculating snaps to objects that are actually too far away for snapping to. Is that a correct assumption or is there something else going on with snapping and snap settings that could be used to reduce lag if set properly in VW2018?


No clue WHAT specifically is happening, but I have noticed similar behavior. With snapping and/or selection highlighting disabled completely, things move much more smoothly. 

Selection highlighting makes sense, since it still hasn't been transitioned over to the VGM / graphics card. (From what I have heard, the highlighting is slated to be transitioned over relatively soon, but no official statement yet.) However I do not know what snapping relies on. We also introduced Master Snaps in 2017 I believe, but I think that was more about where snaps were generated rather than how they were handled.

Link to comment
  • 0
3 minutes ago, JimW said:


No clue WHAT specifically is happening, but I have noticed similar behavior. With snapping and/or selection highlighting disabled completely, things move much more smoothly. 

Selection highlighting makes sense, since it still hasn't been transitioned over to the VGM / graphics card. However I do not know what snapping relies on. We also introduced Master Snaps in 2017 I believe, but I think that was more about where snaps were generated rather than how they were handled.

Maybe it is worth to have a small poll to find out who is having show/snap others active for design layers and whether they suffer from lag and if the lag basically goes away when layer view is set to only show other layers (or any other layer view setting that does not have snap).? This regardless of snap settings in the Snapping palette. This because there are a lot of complaints about the lag but rarely do people mentioned if they have snap enabled in their layer view, and I don't recall anyone mentioning before that it goes away if a setting without snap is used in the layer view setting.

Whatever the cause is of the lag, at least I now have a way to speed up VW2018 quite a bit if I don't have to snap to other layers. :)

Link to comment
  • 0

For me since VW 2017 there were massive problems with Zoom lagging

when the cursor hovers over lots of snappable geometry.

If I put my cursor outside of the Model in blank screen, Zoom works smooth,

no matter how much geometry.

I also think that slower snapping recongnition should be overwritten by or

switched off while Zoom actions.

There were large improvements (over SPs or) with VW 2018. But lag still

sometimes noticeable.

Link to comment
  • 0

I notice in 2018 that snap sometimes just fails to snap. A bit of panning around or zooming in/out sometimes makes it behave again.

 

The comments above about snap maybe searching for too many points "in the background" makes me think of another ongoing problem, which also seems to be related to VW looking for stuff in the background:

 

 

Link to comment
  • 0
7 hours ago, line-weight said:

I notice in 2018 that snap sometimes just fails to snap. A bit of panning around or zooming in/out sometimes makes it behave again.

 

The comments above about snap maybe searching for too many points "in the background" makes me think of another ongoing problem, which also seems to be related to VW looking for stuff in the background:

 

Maybe we should start a wish list request to not only fix the snapping but rework it to make it more reliable and also more usable in 3D as well as sometimes it just fails to snap at all.

Link to comment
  • 0

I'd like snapping to work better in 3D for sure. I am constantly drawing lines on faces as guides to find points.

 

One thing that is very difficult to do at the moment (unless I'm missing something) is to measure, with the tape measure tool, the distance between two parallel faces. For example something as simple as the height of a ceiling relative to a floor. I end up creating a section viewport and measuring on this because it seems the only reliable way to do so. I think it's been requested before but if we could snap to edges of the cut plane in the clip cube, this would be one method of getting/checking the measurements I often want.

Link to comment
  • 0

Something that I'm not sure if it's *supposed* to work or not:

 

In top/plan view where two lines cross each other, but belong to different objects on different planes. Eg. the edge of a slab, and a 2d line drawn perpendicular to it. Should I be able to snap to the "intersection" of these lines (in 3d they don't intersect but viewed in top/plan they do)? Because I generally can't.

Link to comment
  • 0
51 minutes ago, line-weight said:

Something that I'm not sure if it's *supposed* to work or not:

 

In top/plan view where two lines cross each other, but belong to different objects on different planes. Eg. the edge of a slab, and a 2d line drawn perpendicular to it. Should I be able to snap to the "intersection" of these lines (in 3d they don't intersect but viewed in top/plan they do)? Because I generally can't.

Two lines crossing at different elevations are technically speaking not intersecting, so I am not surprised it doesn't snap.

 

Though it would certainly be nice to have an option to be able to snap on apparent intersections in e.g. top/plan view, but then it might be nice for front, left, right, back views as well. The problem with apparent intersections is that it can be very much view dependent, i.e. rotate the view a few degrees and the apparent intersection may be gone, so I doubt it would be possible to snap to apparent intersections unless a flat 2D view can be generated that would then generate actual intersections that could be snapped to. But that begs the question in how far such distances would be correct anyway relative to real world distances and how useful it would be in that case.

Link to comment
  • 0
5 hours ago, line-weight said:

Something that I'm not sure if it's *supposed* to work or not:

 

In top/plan view where two lines cross each other, but belong to different objects on different planes. Eg. the edge of a slab, and a 2d line drawn perpendicular to it. Should I be able to snap to the "intersection" of these lines (in 3d they don't intersect but viewed in top/plan they do)? Because I generally can't.

4 hours ago, Art V said:

Two lines crossing at different elevations are technically speaking not intersecting, so I am not surprised it doesn't snap.

 

This is a situation where its essential to be able to snap in orthographic views otherwise what's the point. You should be able to snap and the object you're working with shouldn't get dragged in and out of the screen plane, it should stay on its existing plane. True orthographic views are supposed to be used in this way and can be in most other programs. If it were possible I could pretty much stop using 2d screen plane objects as guides.

 

Kevin

Link to comment
  • 0
On 1/19/2018 at 10:34 AM, Kevin McAllister said:

 

This is a situation where its essential to be able to snap in orthographic views otherwise what's the point. You should be able to snap and the object you're working with shouldn't get dragged in and out of the screen plane, it should stay on its existing plane. True orthographic views are supposed to be used in this way and can be in most other programs. If it were possible I could pretty much stop using 2d screen plane objects as guides.

 

Kevin

 

I've been struggling with this since at least 2013: https://forum.vectorworks.net/index.php?/topic/37350-persistence-of-3d-environment-in-2d-front-side-views/

 

Maybe best expressed here: https://forum.vectorworks.net/index.php?/topic/43601-orthogonal-snapping/&tab=comments#comment-220238

 

This seems like such a BASIC thing, how can four years go by without at least an explanation as to why we all need to somehow learn to perceive the movement of objects perpendicular to the screen when working in orthographic views???   VWIS077

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...