<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
<tt>Walt, <br>
<br>
1) I don't follow this question<br>
2) No attribute data is available. <br>
3) 67-50 map layers, all themed with varying levels of complexity (Most
complex layer has 25 themes). Some are organized into groups, others
are not. <br>
4) No custom processing, this is just our map "out of the box"<br>
<br>
I am pretty confident that the problem here is the legend. If I turn
off all layers in the legend and pan, it still takes 4 to 5 seconds
(the progress bar hangs at around 50%) for the update to complete. I
turned off legend visibility for each layer in my map, and now the map
performance is significantly better (progress bar always just zips
right through). Note that if i only turn off the Legend via the Layout,
I still have bad performance. <br>
<br>
Very weird, especially given that as you say, the legend is downloaded
at the beginning. <br>
<br>
I am going to try and use Fiddler to look at the DWF. I had no idea
that would/might work. Will let you know how that goes. <br>
<br>
Joel<br>
<br>
</tt>Walt Welton-Lair wrote:
<blockquote
cite="midA4F4647B12DBAD40B07041547CA25264072989@msgusaebk01.autodesk.com"
type="cite">
<pre wrap="">Joel,
This newsgroup is the right place to ask questions about DWF Viewer behavior in the context of MapGuide.
Regarding your DWF problem, it looks like about half the time is the server generating the update, the other half is downloading / processing of the update. Some other questions I have:
- If you mouse down and pan or zoom, is the redraw performance ok? If it's slow then that can contribute to the processing time for the update. When graphic resources are processed the viewer does periodic redraws of the scene graph.
- Have you made any feature attributes available on your layers (so that selecting a feature will display the attributes in the property window)? Attributes are separate resources in the EMapTransaction DWF. While they're being processed the progress bar will not move, nor will you see any graphics updates. You should only notice a pause though if you have a large number of features with attributes. These also compress very well in the EMapTransaction. So the progress bar will update only briefly, but then there's a lot of processing that might need to happen once it's uncompressed.
- How many layers are in your map? Each visible layer that needs to be updated will add to the number of DWF resources in the update (one for primary graphics + tooltips / hyperlinks, another for any lables, and another for attributes). Unless you have hundreds of layers I don't think this should be a problem. In fact if all the resources are small then the progress bar should move relatively smoothly since each resource won't take long to process.
- Are you doing any custom server-side processing, like dynamically adding/removing/refreshing layers? That will add to the information in the update.
- How many of your layers are point layers with labels? Those add a fair amount of data in the labeling resource.
Other notes:
- Information in the legend is downloaded at the beginning, so that's not the problem. The only other time legend info is downloaded is if you add a new layer.
- An easy way to test processing time per layer is to simply toggle each one off and then back on in the legend. Only the resources for that one layer will be upated. Maybe one of the layers will stand out...
- For the DWF Viewer API docs try first doing a quick search of the MapGuide newsgroups on Nabble - there's a number of threads where I've posted these.
- Another interesting thing to try is to capture one of te EMapTransaction updates in the server response. I think Fiddler (<a class="moz-txt-link-freetext" href="http://www.fiddlertool.com">http://www.fiddlertool.com</a>) might let you do this. You can then open the DWF using a zip utility and see the individual resources.
Walt
-----Original Message-----
From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a> on behalf of Joel Carranza
Sent: Mon 2/12/2007 8:44 PM
To: MapGuide Users Mail List
Cc:
Subject: Re: [mapguide-users] DWF Viewer progress bar?
Thank you for this information Walt, this is helpful. The problem that
we are seeing is that a typical map update may take anywhere between
approx 7-12 seconds. Half of that time is spent w/ the hourglass
showing, and half of that time is being taken up with the progress bar
displaying (sometimes no progress shown, sometimes halfway through).
I've zoomed way in before, and had the map progress bar display almost
immediately, but I still have to wait maybe 4 or 5 seconds before the
update is complete. The number of map features we are talking about here
is less than 10.
So what could be soaking up so much CPU/Bandwidth? This isn't exactly a
lightweight machine (3.4 GHZ, 1GB of RAM, the server is on another
machine but within our local network). Could it be:
- stylization? all out objects are themed with various line style and
weights
- tooltips? Most of our map features have multi-line tooltips.
- the legend? All our layers are being displayed in the legend. When
does this information come down?
I'm taking stabs in the dark here. Any hints might be useful.
Is it possible to hook into the DWF Viewer API to look at processing
times on a per layer basic?
I can't seem to find the DWF Viewer API docs? Are these available on the
web?
Final question, i promise....
Is this even the correct place to ask this question? I find myself
confused in regard to where I should post any given question,
considering the overlap between almost all the groups.
--Joel
Walt Welton-Lair wrote:
> The progress bar measures the total download progress for the map
> update. Here's what happens in detail:
>
> 1/ the DWF Viewer requests a map update from the server
> => hourglass cursor is shown, but no progress bar yet
>
> 2/ the response from the server (an EMapTransaction DWF) begins
> streaming in
> => the progress bar is turned on and starts updating
>
> 3/ the EMapTransaction is a compressed file containing a sequence of
> resources:
> a descriptor, graphic resources (W2Ds), and object definition data
> (attributes)
> => while a resource is being downloaded the progress bar updates
> => once a resource is fully downloaded it's immediately processed
> * the progress bar does not update during processing
> * depending on the size of the resource it may take some time
> to process it, e.g. a layer with dense graphical data
> => after the resource processing completes the next resource in the
> server
> response is read
> * the progress bar updates some more
>
> As far as the dual progress indicators, those are used in the context of
> multi-page EPlot and EModel DWFs. One of the bars indicates the
> progress for loading the current page, while the other indicates
> progress for loading the entire DWF. EMaps don't have multiple pages,
> and so the two indicators always have the same position.
>
> Walt
>
> -----Original Message-----
> From: <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users-bounces@lists.osgeo.org">mapguide-users-bounces@lists.osgeo.org</a>
> [<a class="moz-txt-link-freetext" href="mailto:mapguide-users-bounces@lists.osgeo.org">mailto:mapguide-users-bounces@lists.osgeo.org</a>] On Behalf Of Joel
> Carranza
> Sent: Tuesday, February 06, 2007 10:05 PM
> To: MapGuide Users Mail List
> Subject: [mapguide-users] DWF Viewer progress bar?
>
> Perhaps this is a silly question, but here is goes:
>
> Does anybody know exactly how the progress bar in the DWF operates? On
> each map request, there seems to be three stages...
>
> 1) No progress bar (no significant CPU activity)
> 2) Progress bar appears with very tiny amount of progress (CPU starts
> working)
> 3) Progress bar updating and map updating (CPU is working)
>
> There are actually two different progress bars (one on top of each
> other) which are working in tandem with each other. Does anyone know
> precisely how to interpret them? The Below URL explains for a
> multi-sheet DWF.
>
> <a class="moz-txt-link-freetext" href="http://dwf.blogs.com/beyond_the_paper/2006/09/dwf_progress_ba.html">http://dwf.blogs.com/beyond_the_paper/2006/09/dwf_progress_ba.html</a>
>
> How does one interpret them in the context of a DWF map? Specifically,
> we are wondering about the pause at stage #2. Is that when the client
> has started recieving data, recieved all data? Is the pause at stage #2
> utterly insignificant? Anybody know?
>
> --joel
>
>
> _______________________________________________
> mapguide-users mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
>
> _______________________________________________
> mapguide-users mailing list
> <a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
> <a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
>
>
>
>
>
_______________________________________________
mapguide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
</pre>
<pre wrap="">
<hr size="4" width="90%">
_______________________________________________
mapguide-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:mapguide-users@lists.osgeo.org">mapguide-users@lists.osgeo.org</a>
<a class="moz-txt-link-freetext" href="http://lists.osgeo.org/mailman/listinfo/mapguide-users">http://lists.osgeo.org/mailman/listinfo/mapguide-users</a>
</pre>
</blockquote>
</body>
</html>