[OSM-dev] Experiment: AJAX and <canvas> based online editor

[Etienne]

On 8/18/06, Jon Burgess <jburgess at uklinux.net> wrote:
>
> 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()).


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.

Etienne

        Jon
>
>
>
> _______________________________________________
> dev mailing list
> dev at openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/dev/attachments/20060818/a1d5da93/attachment.html>