On 8/18/06, <b class="gmail_sendername">Jon Burgess</b> <<a href="mailto:jburgess@uklinux.net">jburgess@uklinux.net</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, 2006-08-18 at 14:24 +0100, Nick Whitelegg wrote:<br>> you can see a demo. Wait until the data has been downloaded then try moving<br>> using the buttons. Drawing the nodes, segments and ways becomes progressively
<br>> slower as more data gets loaded in - it thus seems the rate determining step<br>> is less the rendering but more looping through the nodes, segments and ways.<br>> This is on a fast machine (Linux, Firefox 
1.5, 1gb ram, 3GHz)<br><br>> On the other hand, does anyone have any general tips on improving drawing<br>> performance? This also applies to osmeditor2 which is also rather slow when<br>> drawing data - even though it does not attempt to draw things outside the
<br>> current viewing area. The algorithm at present is more or less:<br><br><br>I tried running the Venkman Javascript profiler<br><a href="http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#profiler">http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#profiler
</a><br><br>Here is part of the output sorted by "time excluding calls in ms" and<br>slightly reformatted:<br><br>    Function Name: main.js - callback  (Lines 82 - 164)<br>    Total Calls: 6 (max recurse 0)<br>
    Total Time: 72077.02 (min/max/avg 4565.9/35141.7/12012.84)<br>    Time (ex. calls): 41584.65 (min/max/avg 1242.28/28340.5/6930.78)<br><br>    Function Name: OSMData.getNodeById  (Lines 125 - 132)<br>    Total Calls: 20076 (max recurse 0)
<br>    Total Time: 28140.91 (min/max/avg 0/2572.03/1.4)<br>    Time (ex. calls): 28135.23 (min/max/avg 0/2569.02/1.4)<br><br>    Function Name: OSMData.getSegmentById  (Lines 134 - 141)<br>    Total Calls: 8408 (max recurse 0)
<br>    Total Time: 8130.71 (min/max/avg 0/62.14/0.97)<br>    Time (ex. calls): 8130.71 (min/max/avg 0/62.14/0.97)<br><br>    Function Name: TileManager.grab (Lines 101 - 156)<br>    Total Calls: 5 (max recurse 0)<br>    Total Time: 
20547.55 (min/max/avg 0.1/17996.27/4109.51)<br>    Time (ex. calls): 7217.4 (min/max/avg 0.03/4672.69/1443.48)<br><br><br>It isn't clear to me why the XML processing the callback is so slow.<br><br>It looks like the OSMData.getNodeById
 and OSMData.getSegmentById could<br>be improved by using the ID as the array index instead of the a simple<br>linear list.<br><br>I wonder whether you could cache a list of nodes/segments/ways which are<br>visible in each tile, thereby avoiding the exhaustive search of every
<br>item each time the position is updated. Ways and segments may be visible<br>in multiple tiles, but iterating the list of visible items for all the<br>on-screen tiles must be quicker than iterating every item each time.
<br><br><br>OT, I wonder whether we could produde an Ajax map rendering tool by<br>performing XSLT processing using the osmarender.xsl to produce SVG on<br>the fly (via the client side Mozilla XSLTProcessor()).</blockquote>
<div><br>SVG supports javascript event handling, so yes it should be possible to do this.  I've been thinking about this for some time but need one of those very elusive long weekends to try to make something of it.<br><br>
Etienne<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">        Jon<br><br><br><br>_______________________________________________
<br>dev mailing list<br><a href="mailto:dev@openstreetmap.org">dev@openstreetmap.org</a><br><a href="http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev">http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
</a><br></blockquote></div><br>