This single file build process will basically get the application into a initialized / loaded state much quicker. but have no real affect on the time of which the map window is refreshed / paned / zoomed or first loaded. <br>
<br>Cheers<br><br>Paul D<br><br><br><div class="gmail_quote">On Thu, Oct 30, 2008 at 9:57 AM, Andrew Parker <span dir="ltr"><<a href="mailto:andrew@source3.com">andrew@source3.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Paul D:<br>
<br>
I see what you are saying about the perceived perception. I was fooled myself. All I had to do is look at the status bar and count how many seconds it took to download the data. The total time was approximately 13 seconds +/- 1 second to account for map size. I will play around with Mike Adair's suggestion:<div class="Ih2E3d">
<br>
<br>
"Unrelated to the tiling issue, you can optimize the initial loading time of Fusion by creating a singleFile build as per <a href="http://trac.osgeo.org/fusion/wiki/ANTBuildSystem" target="_blank">http://trac.osgeo.org/fusion/wiki/ANTBuildSystem</a> "<br>
<br></div>
to see if I can have Fusion draw the map (tiles?) while the data is being downloaded to make the users think that the UI is fast.<br>
<br>
~andrew.<br>
<br>
<br>
<br>
Paul Deschamps wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
Andrew,<br>
<br>
Unfortunately, in regards to Fusion / Mapserver and it's tiling capabilities this is not something that I am aware of. not to say that it doesn't exist but I have no experience with it. Perhaps someone on the list can weigh in here ;)<br>
<br>
Again as far as the "performance" issue:<br>
<br>
All three demos should have the same performance (openlayers / mapfish / fusion) because they are all openlayers. I think what we are seeing here is a perceived performance issue instead of an actual one:<br>
<br>
I believe is the fact that when fusion is requesting an image it blanks to a white page as an image is requested this gives you a noticeable cue and or illusion of a performance issue were as with a tiled map window, you can see the tiles coming in so you think it's faster.<br>
<br>
Playing around with the map file's size attributes have no effect as they are indeed being overridden by fusion. The map image being requested from the mapserv binary "CGI".<br>
<br>
As far as contributions they are indeed welcome. However lets see if this functionality is not already scheduled to be accomplished already. Perhaps there is a milestone for this in fusion 2.0.<br>
<br>
Anyone what to comment here?<br>
<br>
Cheers<br>
<br>
Paul D.<br>
<br></div><div><div></div><div class="Wj3C7c">
On Thu, Oct 30, 2008 at 8:40 AM, Andrew Parker <<a href="mailto:andrew@source3.com" target="_blank">andrew@source3.com</a> <mailto:<a href="mailto:andrew@source3.com" target="_blank">andrew@source3.com</a>>> wrote:<br>
<br>
Paul D:<br>
<br>
From your post, it is my understanding that Fusion does not have<br>
the capability to use tiles. Is this true? If needed, I have a<br>
programmer that can dedicate his time to add tile functionality. I set the SingleTile tag to "true" then "false" in the MapSet<br>
(file ApplicationDefinition.xml) to see if there was any change on<br>
the way Fusion rendered the map. I did not notice any difference.<br>
I also played around with the map size in the *.map file from<br>
"800 640" to "200 100" to "2000 1000" to see if it made any<br>
difference (curiosity, what else can I say). I did not notice any<br>
difference with respect to speed; I am sure Fusion is overwriting<br>
this setting. I set the final size to "300 300" for no reason at all.<br>
<br>
At this time, I am most concerned with fast rendering of the USGS<br>
topo maps and the Geologic Map. Google is not that important.<br>
But, if need be, I can have the programmer start working on the<br>
OpenLayers.Layers.Google class; I will need a little help to point<br>
him in the right direction.<br>
<br>
~andrew<br>
<br>
<br>
Paul Deschamps wrote:<br>
<br>
Hi Andrew,<br>
<br>
hehe yes or no answer ;)<br>
<br>
What you are doing here is not a "true" comparison of the<br>
three different technologies.<br>
<br>
Your mapfish and your openlayers application are using tiles<br>
where your fusion app is not. You see in a tiled mapwindow<br>
tiles outside of the mapwindow can be cached so that they<br>
display when they are dragged into position. Another<br>
consideration about tiled mapviewers is the size of each tile.<br>
<br>
If the size of the tile requested from the server is requested<br>
at the same native size of the tile on the server then the<br>
server does not need to stitch tiles together.<br>
<br>
All three of these examples are using Openlayers. So from a<br>
strictly fetching of the map image and presenting it on the<br>
screen the performance would be identical as long as the<br>
requested image is the same size across all three.<br>
<br>
And lastly, Your Openlayers app is using Google's Server Farm<br>
directly for it's imagery where the mapfish and fusion are<br>
requesting it. so it's an extra step for every map draw.<br>
<br>
Fusion is a toolkit that provides common set of map "widgets"<br>
and UI controls that enable rapid application development<br>
(RAD) there's a buzz wo from the past. :)<br>
<br>
If you really want fusion to preform in the same fashion that<br>
your openlayers app is. You can:<br>
<br>
Add the OpenLayers.Layers.Google class to your openlayers.js<br>
and get fusion to work with it. ( may or may not be an easy task)<br>
Or wait for it to be added eventually ;)<br>
<br>
Cheers<br>
<br>
Paul D.<br>
<br>
On Wed, Oct 29, 2008 at 5:47 PM, Andrew Parker<br>
<<a href="mailto:andrew@source3.com" target="_blank">andrew@source3.com</a> <mailto:<a href="mailto:andrew@source3.com" target="_blank">andrew@source3.com</a>><br></div></div><div><div></div><div class="Wj3C7c">
<mailto:<a href="mailto:andrew@source3.com" target="_blank">andrew@source3.com</a> <mailto:<a href="mailto:andrew@source3.com" target="_blank">andrew@source3.com</a>>>> wrote:<br>
<br>
I am not sure if there is a way to make Fusion render maps<br>
as fast<br>
as OpenLayers. At this time, I just need a yes or no answer.<br>
<br>
For example, it would be great if I could make my current<br>
Fusion<br>
application (<a href="http://216.93.173.156/testing/" target="_blank">http://216.93.173.156/testing/</a>) draw the map<br>
as fast<br>
as my current OpenLayers application<br>
(http//:<a href="http://webgis.source3.com" target="_blank">webgis.source3.com</a> <<a href="http://webgis.source3.com" target="_blank">http://webgis.source3.com</a>><br>
<<a href="http://webgis.source3.com" target="_blank">http://webgis.source3.com</a>>) and my MapFish test at<br>
(http://<a href="http://216.93.173.156/MFtest/" target="_blank">http://216.93.173.156/MFtest/</a>).<br>
<br>
What I am using for a comparison is the Topo Map Layer with the<br>
USGS wells (the data is limited to New Mexico, USA) at a<br>
scale of<br>
about 1:100,000. When I zoom and pan, I like how fast<br>
OpenLayers/MapFish redraws.<br>
I went ahead and turned on the two layers that I am using for a<br>
comparison in MapFish test and my Fusion test.<br>
<br>
The topo is from TerraServer. The USGS data is in PostGIS.<br>
<br>
thanks,<br>
<br>
~andrew<br>
_______________________________________________<br>
fusion-users mailing list<br>
<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a><br>
<mailto:<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a>><br>
<mailto:<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a><br>
<mailto:<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a>>><br>
<br>
<a href="http://lists.osgeo.org/mailman/listinfo/fusion-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fusion-users</a><br>
<br>
<br>
<br>
<br>
-- Paul Deschamps<br>
Applications Specialist<br>
DM Solutions Group Inc.<br>
<br>
Office: (613) 565-5056 x28<br>
<a href="mailto:pdeschamps@dmsolutions.ca" target="_blank">pdeschamps@dmsolutions.ca</a> <mailto:<a href="mailto:pdeschamps@dmsolutions.ca" target="_blank">pdeschamps@dmsolutions.ca</a>><br></div></div>
<mailto:<a href="mailto:pdeschamps@dmsolutions.ca" target="_blank">pdeschamps@dmsolutions.ca</a><div class="Ih2E3d"><br>
<mailto:<a href="mailto:pdeschamps@dmsolutions.ca" target="_blank">pdeschamps@dmsolutions.ca</a>>><br>
<br>
<a href="http://www.dmsolutions.ca" target="_blank">http://www.dmsolutions.ca</a><br>
<a href="http://research.dmsolutions.ca" target="_blank">http://research.dmsolutions.ca</a><br>
<br>
_______________________________________________<br>
fusion-users mailing list<br>
<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a> <mailto:<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a>><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fusion-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fusion-users</a><br>
<br>
<br>
<br>
<br>
-- <br>
Paul Deschamps<br>
Applications Specialist<br>
DM Solutions Group Inc.<br>
<br>
Office: (613) 565-5056 x28<br>
<a href="mailto:pdeschamps@dmsolutions.ca" target="_blank">pdeschamps@dmsolutions.ca</a> <mailto:<a href="mailto:pdeschamps@dmsolutions.ca" target="_blank">pdeschamps@dmsolutions.ca</a>><br>
<a href="http://www.dmsolutions.ca" target="_blank">http://www.dmsolutions.ca</a><br>
<a href="http://research.dmsolutions.ca" target="_blank">http://research.dmsolutions.ca</a><br>
<br>
</div></blockquote><div><div></div><div class="Wj3C7c">
_______________________________________________<br>
fusion-users mailing list<br>
<a href="mailto:fusion-users@lists.osgeo.org" target="_blank">fusion-users@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/fusion-users" target="_blank">http://lists.osgeo.org/mailman/listinfo/fusion-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br> Paul Deschamps<br> Applications Specialist<br> DM Solutions Group Inc.<br><br> Office: (613) 565-5056 x28<br> <a href="mailto:pdeschamps@dmsolutions.ca">pdeschamps@dmsolutions.ca</a><br>
<a href="http://www.dmsolutions.ca">http://www.dmsolutions.ca</a><br> <a href="http://research.dmsolutions.ca">http://research.dmsolutions.ca</a><br> <br><br>