Pharr

Hi Domer, It's not generally our policy to talk about upcoming products, but this is a special situation. I'll try to provide the important info you are looking for. NNA indicated last June that we would support the Intel Macs as soon as we could, and we are planning to have native Intel Mac support around the time of Apple's announced plans to ship (Summer 2006). VectorWorks 12 users will be able to update to our Intel-native version without additional upgrade fees. Our porting process is less trivial than those being trumpeted on Apple's web site, which seems to have a number along the lines of "It took us only 18 seconds to port to Intel after checking the 'Universal Binary' checkbox. After an additional 8 1/2 minutes of testing, we feel we're ready to ship." ;-) Our porting work for VectorWorks is underway and proceeding according to plan. With respect to rendering speed, we feel that 12 is generally as fast or faster than 11.0 and in some cases, somewhat faster than 11.5. This is a general statement and does not account for the behavior of all possible render modes or mcd files. We are finalizing some numbers in response to a query on a separate thread and plan to post some example numbers later this week. I would expect us to perform similarly on a dual core CPU as on a dual processor machine, but we don't have any actual resuts to share.

We are aware of some Safari related problems which occur on some machines and not others. We are working with Apple and the vendors of our HTML help system to get these resolved. Additionally, we do know that non-current versions of the Java runtime environment cause big problems for the help system. Check your system update status ans make sure you are current. Firefox is our recommended alternative to Safari to get around these help problems.

Hi Eddie, The file you sent me on August 17, 2005 (ABC Childcare) was timed by our engineer to be faster in 12 than 11.5.1 and likely faster than in 11.0.1. I have asked our QA staff to run some fresh numbers with the final release of VW12 as the engineering timings were done with a late beta. We have had similar results with rest files sent to us by Tech Forum user DDDesign. I'll post an update when we have new results. Hi Jeff, I haven't heard from you before on your issues in 11.5. I'll offer the same thing to you as I have offered in the past to Eddie & David who have had past concerns about render speed. Please send me a file representing the problem case and describe what you have noticed - either slowdowns from past releases or geometry problems, and I'll get them looked at ASAP. I'll be glad to let you know what we find.

quote: Originally posted by Viper x: Thanks for you response John. Doing the things you have suggested is like throwing water on a fire without shutting down the source, ie there is still clearly a basic problem with the program. Why is it leaking such memory in the first place ? You are likely correct that the actions you are performing are causing VectorWorks to leak memory. We have been attacking various sources of memory leaks over the last few releases and we plan to continue, but we need to identify the actual operations causing the leaks. Here is what you can do to help. Since it sounds like you are seeing a definite reproducible pattern of some operations causing a significant memory leak, you need to describe those operations to us. The best thing for you to do is to send us a file and a description of the types of editing you are doing during one of these two hour sessions where you notice many hundreds of megabytes being leaked. This should be easy for us to reproduce. If you are unsure of how to describe it, you may want to take a day or two and watch very closely what operations you are doing when memory usage seems to be increasing the most. If we can reproduce the behavior, we can and will fix it. Many other people are not seeing this because we are careful to watch for and fix patterns of memory leaks during development. The operations you are doing which trigger this leak are likely somewhat specialized and depend on some kind of relatively uncommon combination of objects in your drawing and operation patterns during your editing sessions. Thanks, We look forward to hearing from you. You can mail me directly at pharr@nemetschek.net.

quote: Originally posted by mike m oz: Sorry to be pedantic but there is a need to change the terminology. They are component parts of the wall not cavities. Cavities are nothing ie. empty space. Yes there are cavities in many walls, but the bits we want to see and represent are components of the wall like brickwork or timber stud framing. Curiously - in VectorWorks 12, we have renamed cavities. They are now called... drum roll please... "Components"

If you just zip them and send them to my email address, that should work. If you have trouble doing that, I can give you an FTP site to which to upload them. Let me know. Thanks, Paul

Hi everyone, I like to see these numbers posted like this as it gives us something to work with. It looks like from what has been posted here that the slowdown we're talking about is hidden line rendering and final RenderWorks slowing down significantly between 11.0.1 and 11.5.0. Is this what everyone is talking about? If DD and APE could send files to my email address below which demonstrate these slowdowns, we will very likely be able to do something about it. Otherwise it may be difficult to make headway on this issue. When sending files, please use a very descriptive subject line to avoid your mail being confused with SPAM. Thanks, pharr@nemetschek.net

quote: Originally posted by APE Design Ctr: I just tried the update to 11.51. I have skipped the 11.5 update since i had endless problems with it, and went back to use 11.01. Seems like the issues I was experiencing are solved, but ohhh man this program is slow in OpenGL, and rendering compared to 11.01.! Is it just me? Can you send me a file which demonstrates this? Do you have any numbers describing the slowdown? We'd love to hear more. Thanks, Paul Pharr CTO Nemetschek North America pharr@nemetschek.net

Hi Mr. Armstrong, The export VectorScript functionality which is getting so much attention in this thread is simply not intended for what you are using it for. It is intended only as a tool to allow VectorScript authors a quick and easy way to generate VectorScript code from geometry as a step in the VectorScript authoring process. I believe your long history with the VectorWorks product has colored your view of this feature, as in the past there were times when our technical support staff recommended using export VectorScript in specific limited cases to assist in some kinds of file corruption. More recently, VectorWorks files are far less likely to become corrupt and if they do, there are far better ways to resolve the problems than what export VectorScript will ever accomplish. (Workgroup referencing and the resource browser can both be used in this respect.) If you use export VectorScript, it should only be as a tool to identify objects which may have some kind of problem. VectorScript itself (as opposed to the export functionality) is quite stable and robust and is used to implement many mainstream features within VectorWorks when used for its intended purpose.

Hi Everyone, Nemetschek North America will be releasing a service pack for the Windows version of VectorWorks shortly. It resolves the problem being discussed on this forum where the VectorWorks application will crash at random and unpredictable times. As this problem only affects the Windows version, we are not releasing an equivalent Mac service pack at this time. You will find the new release on our downloads page within a couple of days. Please note that this release is not our traditional x.x.1 maintenance release. You can expect to see an 11.5.1 release later this year which contains additional fixes for other problems. We feel that the Windows stability issues being experienced by some of our Windows customers are serious enough to warrant the release of an unscheduled service pack to address them.

Hi everyone, We want to investigate all instances of this Windows crashing pattern you are describing. We are gathering contact information for you and NNA intends to contact you over the next few days to determine exactly what you are seeing. If you identify any patterns of crashing (more often crashing when using certain files or after doing certain things) we will be eager to discuss these details with you. If you are experiencing this type of random crashing behavior described in this thread, feel free to contact me with details. Please include email and phone contact info if possible. You can include sample files if they seem to be linked to the behavior. My email is: pharr (at) nemetschek.net Thanks, Paul Pharr CAD Software Manager Nemetschek North America

quote: Originally posted by alanmac: I should think the thread concerning speed issues in VW 11 on a Mac is enough to make anybody with VW10 and a Mac hold fire on upgrading. Don't wish to point the finger either, it's not working right, bottom line, and needs fixing. The irony of this situation is that the slowdown which has been the subject of the recent VectorWorks 11 speed discussion affects VectorWorks 9.5, 10, and 10.5 to the same extent as VectorWorks 11, but is subtle enough that it's difficult to notice when working with most files. The selection slowdown is caused by MacOS X 10.3 - not VectorWorks. As I posted in the other threads, we anticipate a fix from Apple in MacOS X 10.4.

The problem is that the animator can only accelerate the camera within a limited range if it is to maintain smooth motion. The height of the sliders for each frame is specifying the velocity of the camera as it passes that point. If you combine keyframe locations that are close in distance but separated by a rather long time interval and velocities that are high, then you're requesting a situation that is physically impossible without passing the second point and returning to it going the other direction. Having explained that, all you need to do is lower your velocities by sliding the velocity sliders down each keyframe control. No matter how close the keyframes are in space, if you specify zero velocity at the keyframe, negative motion is never necessary. [ 11-04-2004, 09:43 AM: Message edited by: Pharr ]

Hi everyone, This selection speed issue is caused by a bug in MacOS X 10.3. We expect it to be fixed in MacOS X 10.4, but as it is a problem with the MacOS call we use to paint inverted rectangles to the screen to draw selection handles, there is no way we can fix this problem in our code. MacOS X 10.2 and prior do not exhibit this problem. See my previous post from August 4 in this thread: http://techboard.nemetschek.net/ubb/ultimatebb.php?ubb=get_topic;f=12;t=003787

Klaus, I think you're being a little disingenuous here. We investigated the speed problem you reported, found it to be a problem introduced in MacOS X 10.3, reported it to Apple (radar #3752512), and gave you a good workaround. The workaround does not have anything to do with classes - simply group some of your objects using the "Group" command. Drawings with over 100,000 independent objects on the main layer without any kind of structure or grouping are far from common, and even without the MacOS X speed problem caused by Apple's bug you'd have about a 10 second wait to select all of these. I also didn't say that 10.4 "might" fix this problem - I said that we believe 10.4 will fix this problem. We have tested using the current beta of 10.4 and it solves this problem, but I can't commit that the final release of 10.4 won't have this problem, because it hasn't been created yet. In fact, the reason we couldn't have found this problem before the release of 10.3 is that beta 10.3 (7A179) did not exhibit this problem. It was introduced in the final shipping version of MacOS X 10.3. I'm responding with these details to fill in some of the information gaps evident in this thread. NNA is committed to maintaining good performance on Mac and Windows platforms. The Mac has been more challenging due to the rate of change MacOS X is experiencing, but we are comitted nonetheless to do what we can to solve problems as they arise. Thanks, Paul Pharr CAD Software Manager Nemetschek North America

Hi everyone, I'll give you an update on what we have found regarding this problem. Klaus was experiencing some extreme slowdowns on MacOS X in selecting and deselecting objects. He recalled that the same files on MacOS 9 were much more responsive. There were a combination of issues at play in his case. First, his drawings contained many objects (over 100,000) at the top level of the layer he was working with. Grouping these objects or creating a symbol out of some eliminated the selection delay on the main layer. Nevertheless a selection slowdown remains. Our QA staff investigated and found that the slowdown was introduced primarily by the MacOS X 10.3 upgrade after which a selection operation which would take seconds on 10.2.8 became a 10+ minute operation. We have reason to believe this has been fixed for MacOS X 10.4 (Tiger), but we will be following up with Apple to make sure. If you are experiencing unacceptable slowdowns when selecting or deselecting objects on MacOS X 10.3.x, your options include: Structure your drawing more effectively using groups and symbols to reduce the number of objects which must be selected or deselected at a time. Revert to MacOS X 10.2.8 Wait for MacOS X 10.4 Thanks!

Hi klaus, We have heard enough about strange slowdowns in certain situations on MacOS X that we believe there is something going on, but we have yet to find a consistent case which allows us to investigate. Would you be willing to work with our QA staff to help us narrow this down? If so, please contact me directly at pharr@nemetschek.net. Thanks! Paul Pharr CAD Software Manager Nemetschek North America

Can you FTP it? See the Sample Files Page. I'll send it over to Dave if you can upload it to our site. Thanks!

This is the result of a printer driver problem Apple introduced in MacOS X 10.2. One of the installed print drivers opens many files that it does not close. We introduced this warning for VW 10.5 so you have the opportunity to restart and avoid the problem before you crash. I expect MacOS X 10.3 to resolve the problem.

Hi everyone, We need VectorWorks test files to supplement our existing test file library. Please go to the following URL and follow instructions to submit test files for our use during the development of future versions of VectorWorks. http://www.nemetschek.net/samplefiles/ I want to find as many good test files as I can over the coming few days, so please don't wait. Send me what you have as soon as you can. Thanks!

Hi Colin, Thanks for the file. The issue causing the leaks is the hatching applied to your walls. If you remove that, then the leaks disappear. We have prioritized this fix for 10.5.1. Until then, you can use cavity fills, patterns, colors, or class attributes with hatching to work around the problem. Thanks!

Hi Colin, Can you send a file which exhibits this behavior to pharr@nemetschek.net? Thanks!

Are you saying that 10.5 is slower than previous versions of VectorWorks? If so, please send me details and include a file which exhibits this performance degradation. We'll take a look. Send it to: pharr@nemetschek.net Thanks!

The safest thing to do is to avoid 10.3 until your software (including VectorWorks) supports it. If you need to upgrade to 10.3 for some reason then we are providing you with a relatively untested (beta) version of our software which fixes the known problems. Known problems include relatively frequent crashes when using the application and especially when printing. VectorWorks 10.5.1 is the only version of VectorWorks which will avoid these problems. Users of prior versions of VectorWorks should upgrade to 10.5.1 before upgrading to MacOS X 10.3.

There is a problem which is fixed in VW 10.5 where certain print drivers return non-standard data and can result in document corruption. Known instances of this include a handful of Japanese language printer drivers as well as the HP DesignJet 100/120. We are unaware of this problem with DeskJet drivers, but that may be the root of your issue. I think VectorWorks 10.5 has a pretty good chance of resolving it if it is a related HP print driver issue. Donald - there is no doubt that while MacOS X is a more robust operating system than MacOS 9, the application environment under MacOS X has challenged VectorWorks' reliability because of changes in the way many APIs work. We are working with Apple to identify and resolve these issues, and a number of fundamental improvements are in the works for Apple's next MacOS X release.