[OSM-dev] Experiment: AJAX and <canvas> based online editor
Jon Burgess
jburgess at uklinux.net
Fri Aug 18 20:31:19 BST 2006
On Fri, 2006-08-18 at 14:24 +0100, Nick Whitelegg wrote:
> you can see a demo. Wait until the data has been downloaded then try moving
> using the buttons. Drawing the nodes, segments and ways becomes progressively
> slower as more data gets loaded in - it thus seems the rate determining step
> is less the rendering but more looping through the nodes, segments and ways.
> This is on a fast machine (Linux, Firefox 1.5, 1gb ram, 3GHz)
> On the other hand, does anyone have any general tips on improving drawing
> performance? This also applies to osmeditor2 which is also rather slow when
> drawing data - even though it does not attempt to draw things outside the
> current viewing area. The algorithm at present is more or less:
I tried running the Venkman Javascript profiler
http://www.hacksrus.com/~ginda/venkman/faq/venkman-faq.html#profiler
Here is part of the output sorted by "time excluding calls in ms" and
slightly reformatted:
Function Name: main.js - callback (Lines 82 - 164)
Total Calls: 6 (max recurse 0)
Total Time: 72077.02 (min/max/avg 4565.9/35141.7/12012.84)
Time (ex. calls): 41584.65 (min/max/avg 1242.28/28340.5/6930.78)
Function Name: OSMData.getNodeById (Lines 125 - 132)
Total Calls: 20076 (max recurse 0)
Total Time: 28140.91 (min/max/avg 0/2572.03/1.4)
Time (ex. calls): 28135.23 (min/max/avg 0/2569.02/1.4)
Function Name: OSMData.getSegmentById (Lines 134 - 141)
Total Calls: 8408 (max recurse 0)
Total Time: 8130.71 (min/max/avg 0/62.14/0.97)
Time (ex. calls): 8130.71 (min/max/avg 0/62.14/0.97)
Function Name: TileManager.grab (Lines 101 - 156)
Total Calls: 5 (max recurse 0)
Total Time: 20547.55 (min/max/avg 0.1/17996.27/4109.51)
Time (ex. calls): 7217.4 (min/max/avg 0.03/4672.69/1443.48)
It isn't clear to me why the XML processing the callback is so slow.
It looks like the OSMData.getNodeById and OSMData.getSegmentById could
be improved by using the ID as the array index instead of the a simple
linear list.
I wonder whether you could cache a list of nodes/segments/ways which are
visible in each tile, thereby avoiding the exhaustive search of every
item each time the position is updated. Ways and segments may be visible
in multiple tiles, but iterating the list of visible items for all the
on-screen tiles must be quicker than iterating every item each time.
OT, I wonder whether we could produde an Ajax map rendering tool by
performing XSLT processing using the osmarender.xsl to produce SVG on
the fly (via the client side Mozilla XSLTProcessor()).
Jon
More information about the dev
mailing list