Jump to content
  • 11
line-weight

Top/plan panning/zooming sluggish in VW2018

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

Share this post


Link to post

Recommended Posts

  • 0

I haven't read this whole thread, but, seems it may have wandered off topic?...

 

Working on Sheet Layers is TERRIBLE!!!  Zooming and panning are slow, sluggish, laggy, and even invisible.  Random blinking and jumping.  EXTREMELY frustrating, not to mention non-productive.  Vectorworks seems to be in a constant state of "who, me?  you want me to regenerate that geometry?..."  I have way more than enough computing and graphics power.  At best, the only difference the various Navigation Graphics settings might make is to improve one behavior, only to make another worse.  PLEASE FIX THIS!!!    VWIS099

Share this post


Link to post
  • 0
19 hours ago, willofmaine said:

Working on Sheet Layers is TERRIBLE!!!  Zooming and panning are slow, sluggish, laggy, and even invisible.


The majority of the slowness remaining on Sheet Layers is because they have yet to be switched over to the VGM, they still redraw things the old way. This will change relatively soon.
 

Separate from that, we've isolated another few issues causing undue slowness in Top/Plan. Thanks to a test file from @jeremyb we identified a hangup related to complex line types being applied to high vertex count polygons, when the two interact they slow WAY down, more so than would be expected for how complex they would be on their own. Engineering is looking into what can be done to avoid this.

I may post random updates like this in this thread, since the slowness being reported is widespread but the causes are not all identical.

  • Like 1

Share this post


Link to post
  • 0
29 minutes ago, JimW said:

The majority of the slowness remaining on Sheet Layers is because they have yet to be switched over to the VGM, they still redraw things the old way. This will change relatively soon.

 

^ This is an interesting piece of information I was unaware of. I thought all 2d and Top/Plan navigation had already been moved over to the VGM. I assumed this included Sheet Layers since they are inherently 2d and always appear in Top/Plan. This explains so much about why certain bugs haven't been fixed - the offset highlighting for perspective sheet layer viewports being one of them.

 

Kevin

Share this post


Link to post
  • 0
2 minutes ago, Kevin McAllister said:

This explains so much about why certain bugs haven't been fixed - the offset highlighting for perspective sheet layer viewports being one of them.


Interesting related note: Selection Highlighting is also NOT drawn by the VGM yet either, which contributes to a lot of added slowness when selecting many or highly complex objects and explains why disabling Selection and Preselection Highlighting speeds things up so dramatically. This is also being switched over as well, but I am not sure when.

Share this post


Link to post
  • 0

So, while it was technically accurate to say that top/plan viewing was switched over to the VGM for VW2017, in fact a somewhat significant portion of the task remained incomplete.

Edited by line-weight

Share this post


Link to post
  • 0
3 minutes ago, line-weight said:

So, while it was technically accurate to say that top/plan viewing was switched over to the VGM for VW2017, in fact a somewhat significant portion of the task remained incomplete.


Oh yes, the VGM conversion is still ongoing, it will continue to be switched over in chunks as development continues. We mostly targeted the areas that would see the most benefit first and the rest is now following along. This task was far too large to be done all at once.

Share this post


Link to post
  • 0

Well that explains why my fancy new 27" 4K second monitor on my 6 core mac pro with a fancy graphics card, sucks. (graphics lag in plan, visibiliy tool is on holiday, and whatever you do don't zoom in or out on a sheet). 

 

Any idea when this gets fixed?

Share this post


Link to post
  • 0
Just now, jnr said:

Any idea when this gets fixed?

 

1 hour ago, JimW said:

This is also being switched over as well, but I am not sure when.

 

Share this post


Link to post
  • 0
2 hours ago, JimW said:

The majority of the slowness remaining on Sheet Layers is because they have yet to be switched over to the VGM, they still redraw things the old way. This will change relatively soon.
 

Separate from that, we've isolated another few issues causing undue slowness in Top/Plan.

 

Are only Sheet Layers still non-VGM,

or also DLVPs, or VPs itself ?

 

I have a DWG 2D Import referenced by a VWX Container File as a DLVP.

(I even centered the DWG geometry in Bricscad before importing)

Each time I touch it it reloads, at a speed that looks like I would draw each part myself.

 

Edited by zoomer

Share this post


Link to post
  • 0
8 minutes ago, zoomer said:

Are only Sheet Layers still non-VGM,

or also DLVPs, or VPs itself ?

 

I have a DWG 2D Import referenced by a VWX Container File as a DLVP.

(I even centered the DWG geometry in Bricscad before importing)

Each time I touch it it reloads, at a speed that looks like I would draw each part myself.


I don't know the exact answer to this as it is a very complex system that is still incomplete, but I do know that many things that "reference" other portions of a document (not exactly the same concept as a referenced image or DWG for instance), such as viewports, section viewports, design layer viewports, referenced symbols along with a few others are either not yet handled by the VGM at all, or are only partially handled by it.

Share this post


Link to post
  • 0

Isn't this an example of another thing where it might have been better to do the whole thing properly before releasing it as a new feature? Get everything working in the VGM first?

 

Although I realise the basic idea of pushing out the switch to the new VGM on the elements with most benefit first is well-intentioned, it just sets people up to be disappointed. Because I think most people, when seeing that "top/plan" rendering is going to smoother and quicker, would assume that for example sheet layers would be included in this improvement.

 

And really, if the reality is that things like having selection highlighting, or referenced symbols, in actual top/plan view, compromises everything, then it's a bit misleading to say that it's been implemented in top/plan. Especially as it was sold as something that would speed up operations on complex/large files (I seem to remember demonstrations manipulating the street plan of manhattan, or something like that) and most people who work with large/complex files are very likely to have things like referenced objects going on.

 

As ever, I'm not having a go at you JimW, just VW policy on this stuff. Surely stuff like this not only annoys users but loses the impact of all the work that goes into rewriting the relevant parts of the programme - because lots of people find they don't really see a big improvement, and wonder why.

 

Edited by line-weight

Share this post


Link to post
  • 0

OK, so it is maybe not the Sheet Layers itself but the VPs.

So maybe an empty VP with complex Annotation Space drawings is not slow on a SL.

 

I never had any lags in Sheet Layers, but my generated drawings were always quite simple.

My only real 2D usage is underlay drawings, so DLVPs.

And these have always been problematic for me since 2014.

But not as extreme as my current underlay, in VW 2018.

 

 

Share this post


Link to post
  • 0
Just now, line-weight said:

Isn't this an example of another thing where it might have been better to do the whole thing properly before releasing it as a new feature? Get everything working in the VGM first?


I had thought so initially as well until I saw how many possible problems can (and did) arise just from switching it over even when not adding new functionality. Modernizing such a deep system sometimes going back into decades-old code with huge numbers of ties to more recent systems. 

Combined with how much slower things would have been in the meantime if we hadn't done OpenGL, then Plan editing etc in phases, it made sense to roll it out in waves. If we hadn't, we would be WAY worse off than we are now with even more major slowness across the board. Changes have happened/are happening to the Beta program so that major features like this will get way more of a shakedown than in previous releases before they go public so that in the future bigger changes could be done in bigger chunks and there wouldn't be any Day 0 nasty surprises, but the Beta program isn't done being updated yet so some features are being handled differently than others.
 

11 minutes ago, line-weight said:

And really, if the reality is that things like having selection highlighting, or referenced symbols, in actual top/plan view, compromises everything, then it's a bit misleading to say that it's been implemented in top/plan. Especially as it was sold as something that would speed up operations on complex/large files (I seem to remember demonstrations manipulating the street plan of manhattan, or something like that) and most people who work with large/complex files are very likely to have things like referenced objects going on.


Apologies if I have misled anyone here in this way. A lot of my work involves going back and forth between Engineers and Users and sometimes terminology used by both can have different definitions in different contexts.

For Engineers, "Top/Plan" is the geometry drawn on the design layer in Top/Plan view. For a user, "Top/Plan" would also functionally include DLVPs, highlighting, control handles, but for an engineer those are different systems entirely and are handled in very different ways. The mistranslation and lack of clarification however would still rest on my shoulders, I'll try to be more clear in the future when I discuss this topic in particular. As complex as Vectorworks can be on the surface, I assure you the internal workings are an order of magnitude more so. A lot of development work like the porting of plan graphics to the VGM is part of a larger attempt to simplify and streamline it's underlying components.

Share this post


Link to post
  • 0
53 minutes ago, zoomer said:

DLVPs.

And these have always been problematic for me since 2014.

But not as extreme as my current underlay, in VW 2018.

 

 

Either deleting the Sheet Layer parts of the Import (with destroyed Hatches)

or the complete Reboot

helped.

 

Everything fine again .....

Share this post


Link to post
  • 0
1 hour ago, JimW said:

 


Apologies if I have misled anyone here in this way. A lot of my work involves going back and forth between Engineers and Users and sometimes terminology used by both can have different definitions in different contexts.

For Engineers, "Top/Plan" is the geometry drawn on the design layer in Top/Plan view. For a user, "Top/Plan" would also functionally include DLVPs, highlighting, control handles, but for an engineer those are different systems entirely and are handled in very different ways. The mistranslation and lack of clarification however would still rest on my shoulders, I'll try to be more clear in the future when I discuss this topic in particular. As complex as Vectorworks can be on the surface, I assure you the internal workings are an order of magnitude more so. A lot of development work like the porting of plan graphics to the VGM is part of a larger attempt to simplify and streamline it's underlying components.

 

I didn't actually mean to imply you'd misled people in your posts here! They have been quite clear.

 

What I meant was that at the release of VW2017 we were told, in promotional materials, that the VGM had been implemented in "top/plan". But I feel that was not an entirely accurate (even if in the wording it might have been technically accurate) statement to make at the time - in the promo materials and advertising.

Edited by line-weight

Share this post


Link to post
  • 0

First of all, thanks Jim for your patient and persistent responses!

 

11 hours ago, JimW said:

The majority of the slowness remaining on Sheet Layers is because they have yet to be switched over to the VGM, they still redraw things the old way. This will change relatively soon.

 

This is good to hear... I think... "relatively soon" being a relative term, and all...

 

In my previous post, I shouldn't have limited myself to Sheet Layers only.  I have a Design Layer which is exclusively all 2D drawings (2D symbols consisting of building section framing and construction details), all worked on in Top/Plan view.  It competes with the Sheet Layers at being terribly slow, laggy, etc..  And even working on Design Layers with the 3D model is sluggish in Top/Plan view.

 

On the bright side, working in 3D can be quite fast, especially working in OpenGL (the iMac Pro crashing issue aside, that is...).

 

I'm just curious (and maybe I'm being dense with this question), but if the VGM (Vectorworks Graphics Module, yes?...), even implemented incrementally as seems to be happening, is supposed to represent speedier graphics, why are VW 2017, and yet again VW 2018, so much more graphically-challenged than VW 2016?...

Share this post


Link to post
  • 0
9 hours ago, willofmaine said:

I'm just curious (and maybe I'm being dense with this question), but if the VGM (Vectorworks Graphics Module, yes?...), even implemented incrementally as seems to be happening, is supposed to represent speedier graphics, why are VW 2017, and yet again VW 2018, so much more graphically-challenged than VW 2016?...


It is more complicated than this (and I don't pretend to fully understand it, I lack the technical knowledge to do so), but I'll try to bundle up my overall understanding after many talks with engineers:

When things are moved over to the VGM, those specific things are faster. Period. We don't release any components switched over to VGM that don't have specifically measurable performance improvements after we have done so. However the ways those things are measured, by their nature, have to be in very specific ways. So engineering will often run somewhat synthetic tests designed to harshly test JUST that specific area.

MOST of the problems we are encountering related to slowness are interactions between different systems or objects or attributes that were worked-around or smoothed over in prior versions using older tech but whose inefficiencies and hangups are made WAY more obvious by the recent improvements. This was of course unintentional, but that's where I see the most problems.

I will give a loose example that I'm over-generalizing but helps explain this: We recently identified a bug that relates to complex Line Types interacting with high or dense vertex polys. There is a check that the VGM does before redrawing the screen when you have Best Performance enabled on vertices to interpret how a Line Type should be applied to it when it has segments shorter than the segments of that Line Type. (This is evidenced by engineers running a DEBUG version of Vectorworks that profiles the actions Vectorworks takes and shows them what's delayed, but can be seen in our regular versions by watching the Activity Monitor light up one single core and the rest sitting idle for long periods of time.) That check is still done by Core or another similar single-threaded process that has not moved over to the VGM or been split into a multithreaded process yet. That means that the VGM is now triggering a very slow event to happen over and over that the OLD system never triggered so frequently. So this was merely a minor oversight, but it leads to the completely true assessment that "IT WAS FASTER THREE VERSIONS AGO!" from a user's perspective.

My personal feeling is that the best way to address problems like that going forward is to significantly bolster and increase the size of the Beta program to provide a wider variety of hardware and file configurations for us to test before releasing a version with multiple issues like this to the public, and management seems to agree with me more and more. I can not count the number of times engineering had gotten reports of an issue and was stymied in finding the cause until someone came along with an example file showing a sort of Perfect Storm bug that led to a fix being pushed in the next patch. The more frequently we can make that happen and the faster we can get things like that into engineering's hands, the faster things will improve on the user's end as well.

Share this post


Link to post
  • 0
4 hours ago, JimW said:

My personal feeling is that the best way to address problems like that going forward is to significantly bolster and increase the size of the Beta program to provide a wider variety of hardware and file configurations for us to test before releasing a version with multiple issues like this to the public, and management seems to agree with me more and more. I can not count the number of times engineering had gotten reports of an issue and was stymied in finding the cause until someone came along with an example file showing a sort of Perfect Storm bug that led to a fix being pushed in the next patch. The more frequently we can make that happen and the faster we can get things like that into engineering's hands, the faster things will improve on the user's end as well.

 

Encouraging to read this. Thanks.

Share this post


Link to post
  • 0
4 hours ago, JimW said:


It is more complicated than this ... ... ... the faster things will improve on the user's end as well.

 

Thank you for your explanation!  Hopefully Vectorworks, Inc., will throw a lot more resources at the Beta program and/or whatever else it takes to turn the current trend around.  There's a thread somewhere here that suggests skipping new features with the next major release and instead making it all about fixing Vectorworks' many issues.  Gets my vote.  New features are useless if we don't have any time for them after spending the day zooming, panning, and developing workarounds...  In the meantime, again, thanks for taking the time to explain!  

Share this post


Link to post
  • 0

Yes, this slowness is killing when you are on a deadline, so I hope the upcoming service pack improves things quite a bit. If things are not back on speed when VW2019 gets released I'm all for dedicating a year to fixing VW for the VW2020 release and skip on new features. Expanding on existing ones to improve them would of course be totally ok.


That being said, I recently read an article saying that the fixes for Spectre and Meltdown can seriously affect performance of the CPU, one of the things being prediction done by the CPU to access data in RAM or when copying lots of small files on a SSD. They gave an example of an nvme SSD slowing down from 147.000 IOPS to 47.000 IOPS in such a situation after the "fixes" for Spectre and Meltdown were applied.
Another post I read was that Windows Fall Creator update caused some API's to be quite a bit slower, though running Windows in safe mode solved this for one of his applications.

Could it be that these two things are also contributing to VW2018's slowdown depending on whether it uses these Windows API's or just the Spectre/Meltdown fixes? I had already read that mostly Win7/Win8 systems would be affected on the Windows side. So I wonder if there is anything to be gained by upgrading the PC or that it would be better to wait and see in how far the upcoming SP's for VW2018 improve things? Also given @jnrmentioning that his high power system is also very slow.
 

Share this post


Link to post
  • 0
Just now, Art V said:

That being said, I recently read an article saying that the fixes for Spectre and Meltdown can seriously affect performance of the CPU, one of the things being prediction done by the CPU to access data in RAM or when copying lots of small files on a SSD. They gave an example of an nvme SSD slowing down from 147.000 IOPS to 47.000 IOPS in such a situation after the "fixes" for Spectre and Meltdown were applied.
Another post I read was that Windows Fall Creator update caused some API's to be quite a bit slower, though running Windows in safe mode solved this for one of his applications.

Could it be that these two things are also contributing to VW2018's slowdown depending on whether it uses these Windows API's or just the Spectre/Meltdown fixes?


A good thought, but this is unlikely, as the slowdowns would translate directly to 2016 and prior versions running today on the same hardware which in most cases it does not. We also do not do a great deal of disk IO other than launching the application unless actively saving or opening a file. 

As for the overall CPU performance decrease after these fixes, they do exist, but they would most affect the longer Renderworks render times, but less so Vectorworks' redraw. As much as I would like to be able to point a finger at something like that, I strongly feel the ball is in our court on this one.

Share this post


Link to post
  • 0
On 2/12/2018 at 8:36 PM, zoomer said:

OK, so it is maybe not the Sheet Layers itself but the VPs.

So maybe an empty VP with complex Annotation Space drawings is not slow on a SL.

 

I never had any lags in Sheet Layers, but my generated drawings were always quite simple.

My only real 2D usage is underlay drawings, so DLVPs.

And these have always been problematic for me since 2014.

But not as extreme as my current underlay, in VW 2018.

The one thing I have noticed in the past is that when using 2D DWG files that have loads of objects it helps to import them into a separate VW drawing and then create a reference to the VW file in your working file. (which I think is what you did).
This takes away quite a bit of the slowdown caused by either referencing the DWG file or having it imported in your working file. However having lots of polygons with lots of vertices will seriously slow things down so you may want to check the DWG file for such items and if possible clean them up, either in the DWG file itself or in the VW file you are using as a container. (use flatten and (repeat) overkill in Bricscad to make sure it is a simple 2D dwg file)

Share this post


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

As for the overall CPU performance decrease after these fixes, they do exist, but they would most affect the longer Renderworks render times, but less so Vectorworks' redraw. As much as I would like to be able to point a finger at something like that, I strongly feel the ball is in our court on this one.

Too bad then, otoh it does mean your colleagues may be able to fix it instead of having to wait for Intel and Apple/Microsoft to fix things.

Another thing I forgot to mention/ask is that things seem to start slowing down after working for a while in a drawing, almost as if there is a memory leak going on. Is this related to the same issues you are tracking or would that be a separate issue?

Share this post


Link to post
  • 0
Just now, Art V said:

Too bad then, otoh it does mean your colleagues may be able to fix it instead of having to wait for Intel and Apple/Microsoft to fix things.

True. It also means that once we get the offended components ironed out, the speed jumps will be SIGNIFICANT for people who have thrown high quality hardware into their workflows, which is some good news.
 

1 minute ago, Art V said:

Another thing I forgot to mention/ask is that things seem to start slowing down after working for a while in a drawing, almost as if there is a memory leak going on. Is this related to the same issues you are tracking or would that be a separate issue?

Separate most likely, the majority of the bugs actively being tracked now related to slowness are reproducible immediately upon launch and don't mention waiting for any period of time before issues arise. I suggest if you have a case where this happens that you post a separate thread and we can work through it.

Share this post


Link to post
  • 0

Yes, Transfer Container File.

I had no Problems with Geometry in Bricscad or VW in my Transfer File.

It is a preliminary design stage, not much geometry.

I did a Purge in Bricscad and another in VW.

The few Hatches in Model Space were intact but I already replaced them with

Color Fill in VW. Also I did a lot of VW restarting.

 

Not sure what it was.

If I just had to reboot - why do I have to reboot at all (?)

If it were the Objects on PaperSpace (Sheet Layer), why does it matter as I do reference

the Design Layers only (?)

 

But until now these DLVPs work well* again on my nMac Pro. No lags so far.

(*except their Crops in Screen Plane Mode that drive me crazy in 3D Views)

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

  • 7150 Riverwood Drive
  • Columbia, Maryland 21046, USA
  • Contact Us | 410.290.5114

 

  • © 2018 Vectorworks, Inc. All rights reserved.
  • Vectorworks, Inc. is part of the Nemetschek Group.
  • ×