pushLatLngAlt perfomances issue

[sylehc]

Hi all,

I've just bought a new computer dedicated to the GE application
development. The configuration is very recent and powerful (4Gb RAM,
1Tb disk, 3.1 Ghz Dual Core cpu, NVIDIA GX2 1Gb Ram).
With my big surprise, while in general the rendering performances are
very impressive, the time to load a polygon is now very long.
I hoped it was a problem of my web application but even using the
google earth plugin demo page (http://www.google.com/earth/plugin/
examples/samples/ , selecting for example "create polygon (circle)"
and set the steps to 500) the problem persists.
On a "normal" or also old computer the computation doesn't take more
than half second but on my new computer takes more than 15 seconds.
Have someone an idea of what is happening ?

thanks, sylehc.

[ManoM]

Hi sylehc,

Are you running Visata or XP? Are your video drivers fully up-to-date?
I know it's a new computer, but update the drivers and check. Also,
make sure you're running latest version of DirectX, 9.0c

Mano

[sylehc]

I'm running XP professional. All windows updates are installed, the
latest nvidia drivers and directx 9.0c. It seems the problem is linked
to the pushLatLngAlt method. Debugging the application with firebug
I've noticed that all the time is spent to load the points while the
display of the polygon is fast as usual.
For me the call to the pushLatLngAlt method is a black box so I don't
know how to find a solution.

sylehc

[bFlood]

I'm pretty sure I'm seeeing the same thing. pushLatLngAlt is slow, the
same polygon added to Google Maps is about an order of magnitude
faster (which seems very odd)

I'm using XP, will check on the drivers but GE is very fast in
general. When I translate the geometry to KML and paste into GE, it's
really fast (leading me to believe this might not be a driver/display
issue)

any thoughts on how I can help debug this?

cheers
brian

> > > thanks, sylehc.- Hide quoted text -
>
> - Show quoted text -

[ManoM]

Hi sylehc,

Can you provide a link to your application so we can try to debug it?

Mano

[ManoM]

BTW, I realize that you've also pointed out the problem using the
samples page, but it would help to see yours as well.

Mano

[sylehc]

Hi ManoM,

you can find the page at the following address:
http://srrs.chelys.it and select any thumbnail on the left panel.

This problem, togheter with the Google Javascript error using Internet
Explorer, is becoming very blocking for me.
I look forward to receive some good news.
Many thanks,
sylehc

[bFlood]

fyi - i see the same delays on sylehc's website

here's a simple test that's very similar to the existing docs
http://12.144.53.37/test/TestPolygon.html

duration (in milliseconds)
10 vertices - ~0.2
100 verts - 1.422
500 verts - 5.6

there is a large cpu spike during the add
Windows XP
FF - 2.0.0.14
IE7

On Jun 24, 12:04 pm, sylehc wrote:
> Hi ManoM,
>

> you can find the page at the following address:http://srrs.chelys.itand select any thumbnail on the left panel.

[bFlood]

can anyone else confirm the performance above? I tested it on 3 other
machine last night and they all had similar delays. Would like to rule
out the video card/drivers if possible

I changed the demo above to add a parseKml test as well. It's really
fast when compared to the api.
http://12.144.53.37/test/TestPolygon.html

that being said, 2 seconds for 100+ vertices is not encouraging. Could
this a cross-process call (to geplugin.exe)/context switch issue? Lots
of little calls across that boundary would certainly slow the process
down. In the shorterm, maybe we can get an "AddRange([array of
coords])" method on coord arrays? If it is a context switch issue,
then large chunky calls would help out (for instance, parseKML is
almost instantaneous)

cheers
brian

On Jun 24, 1:02 pm, bFlood wrote:
> fyi - i see the same delays on sylehc's website
>

> here's a simple test that's very similar to the existing docshttp://12.144.53.37/test/TestPolygon.html

>
> duration (in milliseconds)
> 10 vertices - ~0.2
> 100 verts   - 1.422
> 500 verts   - 5.6
>
> there is a large cpu spike during the add
> Windows XP
> FF - 2.0.0.14
> IE7
>
> On Jun 24, 12:04 pm, sylehc wrote:
>
>
>
> > Hi ManoM,
>

> > you can find the page at the following address:http://srrs.chelys.itandselect any thumbnail on the left panel.

> > - Show quoted text -- Hide quoted text -

[ManoM]

Hi brian,

Yes, I can confirm I'm seeing some slowness there. I'll look into it.

Mano

On Jun 25, 4:38 am, bFlood wrote:
> can anyone else confirm the performance above? I tested it on 3 other
> machine last night and they all had similar delays. Would like to rule
> out the video card/drivers if possible
>
> I changed the demo above to add a parseKml test as well. It's really

> fast when compared to the api.http://12.144.53.37/test/TestPolygon.html

>
> that being said, 2 seconds for 100+ vertices is not encouraging. Could
> this a cross-process call (to geplugin.exe)/context switch issue? Lots
> of little calls across that boundary would certainly slow the process
> down. In the shorterm, maybe we can get an "AddRange([array of
> coords])" method on coord arrays? If it is a context switch issue,
> then large chunky calls would help out (for instance, parseKML is
> almost instantaneous)
>
> cheers
> brian
>
> On Jun 24, 1:02 pm, bFlood wrote:
>
> > fyi - i see the same delays on sylehc's website
>
> > here's a simple test that's very similar to the existing docshttp://12.144.53.37/test/TestPolygon.html
>
> > duration (in milliseconds)
> > 10 vertices - ~0.2
> > 100 verts   - 1.422
> > 500 verts   - 5.6
>
> > there is a large cpu spike during the add
> > Windows XP
> > FF - 2.0.0.14
> > IE7
>
> > On Jun 24, 12:04 pm, sylehc wrote:
>
> > > Hi ManoM,
>

> > > you can find the page at the following address:http://srrs.chelys.itandselectany thumbnail on the left panel.

[ManoM]

Hi sylehc,

I can confirm the problem, and we're looking into it. Have you tried
brian's of workaround of creating the KML and parsing it? It seems to
be considerably faster:
http://12.144.53.37/test/TestPolygon.html

Mano

On Jun 24, 9:04 am, sylehc wrote:
> Hi ManoM,
>

> you can find the page at the following address:http://srrs.chelys.itand select any thumbnail on the left panel.

[bFlood]

hi mano

it's not really a workaround, it was more for comparison. If you could
get the placemark's properties after the fetchKml, it would be
somewhat of a workaround but I think there is an issue with that as
well.

http://groups.google.com/group/google-earth-browser-plugin/browse_thread/thread/ce54452560085526/7becc2e8153ad878?lnk=gst&q=parseKml#7becc2e8153ad878

I think an Add/Update/Delete Range on KMLCoordArray would be better.

On Jun 25, 7:52 am, ManoM wrote:
> Hi sylehc,
>

> I can confirm the problem, and we're looking into it. Have you tried
> brian's of workaround of creating the KML and parsing it? It seems to
> be considerably faster:http://12.144.53.37/test/TestPolygon.html
>
> Mano
>
> On Jun 24, 9:04 am, sylehc wrote:
>
>
>
> > Hi ManoM,
>

> > you can find the page at the following address:http://srrs.chelys.itandselect any thumbnail on the left panel.

[bFlood]

hi all

ok, I think I have a pretty good work around. parseKml works just fine
on subsets of Kml (I thought it needed an entire kml doc) so you can
use it to insert objects into your placemark geometry. I changed the
example above to include the hybrid approach (half api, half parseKml)
and it seems to work really well (please someone correct me if I'm
wrong)

I converted our geometry layer to use this technique and now there
doesn't seem to be any delays when adding/interacting with large
geometries. i guess this is the functional equivalent of "AddRange" so
I'm happy

var geo = ge.parseKml(kmlOfSomeGeometry);
var pm = ge.createPlacemark("");
pm.setGeometry(geo);
ge.getFeatures().appendChild(pm);

var cnt =
pm.getGeometry().getOuterBoundary().getCoordinates().getLength();
console.log("verts " + cnt); //geometry available via api, sweet

http://12.144.53.37/test/TestPolygon.html

cheers
brian

On Jun 25, 8:56 am, bFlood wrote:
> hi mano
>
> it's not really a workaround, it was more for comparison. If you could
> get the placemark's properties after the fetchKml, it would be
> somewhat of a workaround but I think there is an issue with that as
> well.
>

> http://groups.google.com/group/google-earth-browser-plugin/browse_thr...

>
> I think an Add/Update/Delete Range on KMLCoordArray would be better.
>
> On Jun 25, 7:52 am, ManoM wrote:
>
>
>
> > Hi sylehc,
>
> > I can confirm the problem, and we're looking into it. Have you tried
> > brian's of workaround of creating the KML and parsing it? It seems to
> > be considerably faster:http://12.144.53.37/test/TestPolygon.html
>
> > Mano
>
> > On Jun 24, 9:04 am, sylehc wrote:
>
> > > Hi ManoM,
>

> > > you can find the page at the following address:http://srrs.chelys.itandselectany thumbnail on the left panel.

> > - Show quoted text -- Hide quoted text -