Improve AJAX Viewer Load Time

[robertbray]

I have noticed that load times for Maps with a large number of layers (20+) tend to be slow because it takes quite a while to generate and load the individual legend graphic images. In fact the more layers the slower the load time.

It may be significantly better to generate one image strip that contains all of the legend images for a map and have each legend entry display the corresponding portion of the image strip. To further enhance performance that image strip could be cached with the MapDefinition (as resource data) and only be regenerated when the MapDefinition changes. A second strip could be maintained in session state for runtime layer additions to the map.

[pagameba]

Seconded ... I've noticed the same problem. Using CSS to pick out the appropriate image is described here for those that are interested in the details:

​http://alistapart.com/articles/sprites ​http://wellstyled.com/css-nopreload-rollovers.html

How would this be exposed to the AJAX viewer?

[anonymous]

Yea, the key question I think is how does the JavaScript code know what legend graphic will be where in the image? So far every solution I can come up with also requires the server to send down a data structure (JSON?) to describe the image.

I suppose we could use rows and columns, rows being the layers with columns representing each thematic graphic. The problem with this is the image would be sparse and the client still needs the data structure to deal with runtime manipulation of the layer list.

[pagameba]

wow, anonymous sure does a lot of work around here ;)

One possibility. Every potential legend graphic has a particular position in the LayerDefinition. You could build the image strip as a single vertical (or horizontal) strip one legend graphic wide with every legend graphic. The position of the class in the layer definition would be sequential and the legend would just use css to position the image based on the sequential number of that class.

The graphic, and the sequence, would have to be recalculated whenever the structure of the layers changes.

[robertbray]

Yes we could do that, but it kinda sucks to have to mangle the image just because the user created a buffer. Maybe we can do that for the initial load and use a client-side data structure to manage images for dynamically added layers. This adds complexity but it reduces the time required to add a layer. Removed layers would just have dangling images, but that shouldn't be a problem.

[pagameba]

what happens if the order of layers changes in the map? I can see a lot of complications trying to implement this in a way that is generically useful.

Perhaps the best way to address this is to add a GetLegendGraphicStrip operation (returns the image strip) and a DescribeLegendGraphicStrip operation (returns XML - or JSON - that provides the position of each image for each layer/scalerange/rule.

[chrisclaydon]

Modified AJAX viewer code to perform queued loading of legend images to reduce load on browser and server, and to reduce interference with map navigation and re-loading.

1.2.x submission 1542, ​http://trac.osgeo.org/mapguide/changeset/1542

trunk submission 1543, ​http://trac.osgeo.org/mapguide/changeset/1543

[jng]

If we want to talk about improving AJAX viewer load time, we should talk specifics. Otherwise in the general case, load times now are as good as they can get