IanH

It sounds to me like all your problems are centering around OpenGL? OpenGL is implemented within the graphics card. It may be worth making sure that the drivers for the graphics card are up to date and possibly consider a newer card if the graphics card is more than a couple of generations old - VW2009 has additional requirements of the graphics card and it is possible that these have taken it past what the card, or drivers are capable of. It would be sensible to list your hardware so others may comment.

I obviously don't know the VW code, but: 1. NNA need to support 2 platforms - it is unlikely that the majority of the code base will differ much, thus IMHO a rewrite is unlikely although some of the OS specific middleware/application framework could be optimised for each OS. 2. There is more than NNA involved in this. Parasolid, possibly a third part application framework/middleware etc. 3. There will be bits of VW that may well benefit from multi processors/cores but there will be bits that will not. 4. With #1,2 in mind, I doubt that Grand Central will make them any more willing to support full multi core/processor than those features that are already available to them. Even just changing a compiler option (ie optimisation setting), let alone compiler or application framework requires significant testing. 5. There are easier ways to achieve better CPU utilisation than multi threading a single application. 6. Parts of the above will need to be addressed if/when moving to 64bit native so never say never. Re Thom's scenario, I do not believe that an add on package will help existing apps achieve better CPU utilisation. Where existing apps may benefit in the future is from core parts of the OS becoming thread safe, so parts of the OS that currently have to run on a single thread, may in the future benefit from more concurrent execution. This will benefit the app in quicker response from OS calls. But to get most from multi cores/processors, the underlying app needs to be more aware of multi cores - and the benefit of this will be nothing (or even detrimental) for some apps and approaching 100% in other apps. Very much like 32 vs 64bit.

Christiaan My interpretation is based on the expectation that what you have just said had already been built into the OS along time ago. What you are saying makes me doubt that the Apple OS is particularly advanced in multi threading. But I do not think that this can be the case, since Apple OS is Posix compliant and as such multi threading via Posix has been around for the last decade or so. Multi threading is both very simple and very complex. To code a multi threaded app is very easy, to write a multi threaded algorithm and code is can be extremely difficult or impossible. You cannot just take an application and make it multi threaded - it may not suit itself to that. Actually I should clarify this - "and make it concurrently multi threaded". You can take any app and make it multi threaded, but not necessarily run the threads concurrently. I am happy to stand corrected, but my interpretation of what Apple have done is to make their whole/majority of their OS thread safe. What this means is that an application can call an OS routine without having to worry about whether that call interferes with, or interfered with a simultaneous call from another thread. They also hint at technologies to help newer apps. Can I please quite from the apple developers website: And You can see from this that OS-X is, like may other OS's, not totally thread safe and it is up to the application programmer to make their application and algorithm thread aware. I think that apple are just going to make this job easier for the developer - not that it was hard for the coder in the first place. My interpretation from what you and the Apple website have said is that apple are making it easier for applications to become thread aware, which is quite different from running an existing application and having it run across multiple threads as the original post was asking. Some applications are better suited for multi threading than others. Renderworks is multi threaded because rendering scales very well across threads, each scan line is often treated as a separate thread. As is separating an applications user interface from the computational guts of the code. But not all apps will scale so well. Back to the original post - would making each tree run under a different core be useful? Possibly, but only if they did not interact with each other and the overhead of running them across cores did not outweigh the benefits. Some languages are inherently suited to multi threaded applications - object orientation suits MT very well if correctly programmed. How much of VW is object orientated - I don't know, but considering its heritage I would bet money on it not being up there with the most OO of appliations. The ZDNet article posted by Mr Gog does hint at some things that Apple may be looking into. But I don't think its going to transform an old app like Vectorworks like the OP was hoping. I don't want to get into a Mac vs PC war (I first programmed a Mac/Lisa 20 years ago and the application model was beautifully thought out and a joy to work with compared to the MS rubbish), but both camps seem to be about 20 years behind in multi processing technology. In early 90's, I was working on an application that was partly based on the Meiko Computing Surface, an array of 64 Inmos transputers. It was great at doing one job, each rendering their own part of a screen, but, despite its cost, it was left mostly/totally unused as it was simply unsuited to the other applications that we developed and used - despite how much we wanted to use it. It was not a fault of the hardware, nor a fault of the OS, but simply that the application algorithms did not suit multi tasking. No matter what clever technology someone develops, its not going to change for very many apps that simply remain unsuitable for multi threading/tasking/processing/distributed/cored or whatever other grand buzzword people want to use.

I think what you are looking for is the drawing optimiser from vectorbits - can't remember it's proper title.

Yes. If possible, use layers as Ozzie suggests to separate planting areas. I use layers when I am adding textures to a plan. For planting I use three. One for specimen plants that I may want to show in other views - possibly 3D view and another for complex plant massing - the one that kills the machine when you need to update an area. The final one is for canopies where the layer simply gives me a third dimension. I do similar for stipples and gradients as these are also slow to redraw and I'm only interested in them on the final presentation plan.

I'm not a plant tool fan, only using it for indicative spot planting in 3D views or mass planting areas. For planting plans, where placement and labelling is important, I developed my workflow using my own symbols and custom Vectorscript as the VW plant tool does not meet my needs. My projects are much smaller, but even with several hundred massed plants, I have time to make a cup of tea. I generally reverted to the revision or planting line tools and now with 2009, will probably use the landscape area tool as this offers the graphic styles of the revision and planting line tools, under one tool.

Good bit of marketing blurb to make people think they are getting something new. My take on this is that Grand Central is simply going to become more multi threaded. It does very little to enable an app to run across multiple cores. Multi threading has been around for ages - Posix for example, is a standard that has offered multi threading since mid 90's, and some "proper OS's" offered multi threading of sorts much before that. OS-X is Posix compliant, so the only thing that I see that has changed is that the new OS version is more multi threaded - sorry, multicore aware - same thing, different marketing speak. This offers very little benefit to the end application unless the app needs to call a OS routine that was previously not 'thread safe' and thus not able to be used within a multi threaded portion of the application. What I don't see it easing is making a single application more multi threaded. Yes, it talks about making it easier for developers to make multi threaded apps, but that's not the tricky part. The tricky part is making algorithms and data structures able to be multi threaded - and that's the bit that is non trivial.

I doubt it. Writing multi threaded code that is needed to run over multiples processors or cores is a non trivial exercise for all but the simplist code. I can't see that we are at the stage yet where a software app working blind on an application can do better what a human can do with the source code in front of them. The closest we have got to that is pipe lining within the processor which is far simpler than having to deal with mutual exclusion, race conditions and predicting concurrent data and resource contention. However, I last worked on large multi threaded and distributed apps 4 years ago, and technology is a fast mover, so could be wrong. That said, it would be nice if NNA could run the UI and app in separate threads to make the UI more responsive when performing time intensive processes - like some rendering modes or placing large numbers of plants.

IMHO I would not advise using rotate plan as a permanent way of working - 2008 had various glitches with rotated plans, which were fixed in some of the SP's. But I'm still not convinced that things are now 100%. I use it more of a temporary way of working to ease use of some tools, then use viewports to present in the orientation that I ultimately want. I can then fix the things that don't look quite right (ie rotations) direct in the plan, without having to fight a feature that sometimes causes objects to have a mind of their own.

Does anyone know if constraints now use the Parasolid engine? I've just done a few tests with constraints and its been rock solid where as in the past, my use of constraints have caused VW to crash. On that occasion I was using constrain tangent, which thankfully is no longer needed with the new arc by tangent tool. Now I am interested in constrain distance. Just want to know if the stability is down to 2009 changes rather than just the different way that I am using them in my tests. A brief discussion with NNA about constraints in the past implied that 3 constraints were the limit before instability set in. I am now past that limit. Im also interested if there is the possibility of constraints being set by a value range - ie a distance or angle must be within a set range of values. This would open up huge possibilities for me. Unfortunately though, you seem to be unable to put in 0 for a constraint value.

The only thing that my regular account is a member of is the 'Users' group. I wonder if it is anything to do with my VW users folder is not in the standard place but moved to within the My Documents area? I do this for ease of backup. Everything else is probably pretty standard - I didn't play much with Vista when I got my new machine so would expect all permissions to be fairly standard other than disabling the Administrator account and creating an alternative login for administrative purposes as and when needed.

2008 was installed prior to sp1 and 2009 was installed after Sp1 - both behave the same so take your pick!

OK then, just work in metric

This is odd. I run Vista Ultimate with UAC enabled from a non administrator account and VW runs fine without any prompts. UAC did intervene when I first installed VW as I would have expected, but now its installed, everything runs without UAC intervention.

Presumably you successfully opened the Plant Lists.vwx file? If you have, make sure that the resource browser looking at this file. I suspect the resource browser is looking at a different file, possibly "landscape plan" rather than "plant lists". You need to select "plant lists" from the file drop down in the resource browser. The 4 worksheets will be clearly visible in the worksheets folder - which you may need to open to see the contents - make sure the triangle before "worksheets" is in "v" direction not ">" direction.

IMHO, saved views are a working state, sheet layer viewports are for presenting information. You say that you don't do presentations, but even printing out a drawing is presenting it in paper form. You may not need to use viewports when 'presenting' really basic drawings, but it does not take much before you get conflicts between having to draw for the design and drawing to present. Viewports really come into their own by providing pretty much all of the tools needed to *permanently* disassociate the presentation view from the underlying design. Saved views are really a temporary working snapshot of the design. IMHO, if you decide not to use viewports, you are going against a fundamental workflow principle that NNA have designed into VW. That said, I am curious about your employers comment that it is a time consuming process. It takes only seconds to create a sheet layer and viewport and it is normally a one off operation per drawing/view. I wonder whether they is not using viewports in the manner that they are intended if it has become a time consuming operation. In this case, a saved view may well be the correct tool at this stage of the drawing process and that by not feeling that he needs to use viewports when 'presenting' a drawing they are missing other tricks and benefits that VW's use of classes and layers provide. [edit]However, use of sheet layer viewports (SLVP) may not perform as expected if sharing information (it has been pointed out to me that a dxf export of a sheet may not pick up some contents of some SLVP information such as annotations do not get saved in model space but as I do not regularly export in dxf format this is not an issue for me) and of course, the SLVP is only valid for the sheet it is on so cannot be referenced elsewhere - which includes the annotation layer (IMHO the annotation layer is for annotating the sheet not the design so I do not view this as a problem)[/edit] What is important is that viewports and saved views are simply tools, and one will be better than the other in different situations.

My XP laptop does the same with the plant tool (under 2008 not sure about 2009), but Vista PC works fine (even with 2008). I tried your issue with 2009 on my PC and pretty sure that my laptop will behave as it does with the plant tool as the palette selection of hatch and plant tool looks to be exactly the same. I put it down to an issue either with the graphics card drivers or something to do with the box not fully fitting on the screen - but in your case with two monitors, it may not be an issue as you should have plenty of screen space. The other thought is a mouse driver issue.

Have a look at putting begincontext and endcontext around the area that you want to treat as a whole entity. It works similar to database commits where you can rollback a whole set of commands if any single operations fails, but it may do the trick for you too if you set the 'undo click' to endcontext(0) - rollback. That said, a script is treated as a single operation, so running a script, then hitting undo will remove everything created under the script. PROCEDURE test; VAR pt : POINT; BEGIN BeginContext; Rect( 1000, 1000, 1500, 1500 ); Rect( 2000, 2000, 2500, 2500 ); Rect( 3000, 3000, 3500, 3500 ); GetPt(pt.x, pt.y); IF ( pt.x < 1000 ) OR ( pt.y < 1000 ) OR ( pt.x > 3500 ) OR ( pt.y > 3500 ) THEN EndContext(0) ELSE EndContext(1); END; RUN( test ); The above shows the use of the context - it will create 3 'ghosted' rectanges, but not 'commit' them until you click within the bounds of the cluster. If you click outside the bounds, the operation within the context will be rolled back - ie, treated as it had not occurred.

That is extremely similar to Piranesi. Piranesi is more paint orientated where as Impression looks more point and click (which Piranesi can also do) and Impression would seem to benefit from better integration. It is worth checking out what Piranesi can do and it is worth bearing in mind that whilst most examples are 3D orientated, Piranesi can also do 2D.

the use of the parasolids engine has fix many 2D offset issues in 2009. It may be worth geting a demo Cd and trying some of the geometry that you are having issues with.

Hope you can make it so that the note can contain a newline which remains intact when saved and reloaded. Although I have not checked if this is sorted in 2009. I tracked it down to an issue in the 2008 XML code handler - looks like either the reader or writer did not correctly implement xml escaped characters such as linefeed.

I have a script that I posted in the vectorscripts section that copied an object to the current class and layer - it may do what you want. I need to check what state it is in as there was a problem that I found after using it for a few days but I 99% sure it was not the fault of the script as it was so basic but may be an issue with one of the functions it calls.

Wow, the wonders of modern feet and inches!

I don't think its hardware related. Its a array subscript 'soft' error not a hardware generated error. Highly unlikely to have originated from a fixed hardware memory location.

Tried pressing the control key whilst zooming?