Map Redraws Very Slowly

[aggrav8]

I run FSX on a Win7 system with what should be a very capable quad-core system with 6GB memory. But with Plan-G v2.0.5 the only app running, if I zoom or pan view (while building a flight plan), even with only large airports and VORs displayed, sometimes it can take 30 seconds for Plan-G to redraw the display.  It refreshes VORs, then airports, then ILS feathers, then the terrain in increments that take many seconds apiece.  Maybe I have something set up wrong but I haven't a hint of what might be causing this.  Any suggestions for improving the situation will be gratefully received. I can attach screenshots at each stage of the refresh if that might help.
Thanks, a8

[tim arnot]

How fast is your Internet connection? That's probably the limiting factor.

[aggrav8]

I believe my ISP set me up for 7+ Mb/s (I don't recall the specific terminology), but it's quite a speedy DSL.  I wouldn't have thought that if I was running Plan-G that I'd be doing anything with the Internet.  What's the Internet got to do with this?  Anyhow, I did a complete reinstall of v2.0.5 and the redraw doesn't seem to be taking as long now. 

But I do have to wait 15 seconds or so if I zoom/pan and Plan-G has to find and display the new/additional VORs, intersections, etc.  Perhaps 15 sec is normal if I'm telling Plan-G to display:   large/medium airports, VORs/NDBs, and named intersectiions, and I need to be patient.  I just created a plan with only the essential things turned on so Plan-G wouldn't have to redraw them all, and response seems better.  Unless you have a further recommendation, I think I'm ok now.

[tim arnot]

I wouldn't have thought that if I was running Plan-G that I'd be doing anything with the Internet.  What's the Internet got to do with this? 

Plan-G is 100% about the Internet. It's based on Google Maps, which is driven from the Internet. Every pixel of information that is drawn on the map comes via google's servers. So the Internet has everything to do with this.

[aggrav8]

Thanks Tim, for your very civil response.  I've dealt with one forum master who is famed for his sarcasm.  I had no idea that the map data was coming from Google Maps.  I'm glad I decided to buy a reasonably fast connection from my ISP. 

a8

[tim arnot]

Regardless of the ISP's claimed speed, a connection is only as fast as its slowest link, so it may be worth pinging maps.google.com to see what kind of connection you're actually getting. Also, try at tifferent times of the day - it may be a heavily loaded server causing the problem, in which case you'd expect to see variations in he response.

And it may be simply the amount of data you're sending it to draw. Particularly if you're looking at high amounts of detail in a very dense area, such as the USA. Unfortunalely one of the problems with google maps is that it doesn't scale too well with massive data sets, and that's something that for the moment, we just have to live with. The only solution at the moment for that is to display less data - either by shrinking the map window, or displaying fewer overlays.

[aggrav8]

I think I did what you suggested but I don't know how to interpret it.  Please have a look at the attached image.  Is this what you're talking about?

[tim arnot]

Thanks, yes. It's showing 50% packet loss (ie half the data sent doesn't get back), and 79ms round trip time for the remaining packets. In contrast, I'm seeing 37ms with no packet loss on a "up to 10mb" line. So it does suggest that the connection to google is causing at least part of your problem.

I don't know what can be done about it though...

[aggrav8]

I thought that's what it was saying.  Can't do any more than grin and bear it.  I'll just minimize the number of objects displayed while I'm creating flight plans.  Thanks Tim.