[mapguide-users] DWF Viewer progress bar?

Walt Welton-Lair walt.welton-lair at autodesk.com
Tue Feb 13 04:49:13 EST 2007


Ok, now things are making sense.  You have a lot of themed layers, and
it's taking a few seconds to refresh the legend.  This is a full refresh
of the legend, and it's done after applying the EMapTransaction if the
map scale or map center has changed, which is the case when you pan /
zoom.
 
Although the data for the legend is only downloaded once at the
beginning, the refreshing happens after each update.   So there's no
weirdness going on.
 
I don't think there's any need to use Fiddler to look at the
EMapTransaction.  Based on what we now know I'm sure the EMapTransaction
is small and is processed quickly (e.g. the case when you're zoomed in
far).
 
To fix this it looks like DWF Viewer needs some optimization around
updating the legend.  E.g. only refresh it when the map scale crosses a
scale threshhold that causes one or more layers to change its
visibility.  Until that happens, the only way to improve performance
right now is to reduce the amount of information in your legend.  Maybe
you don't need to display themes for some of your layers?
 
I've entered a defect against DWF Viewer regarding this.  In order to
help us reproduce this problem, can you tell me approximately:
- how many of your layers are actually themed, and how many unthemed?
- how many themes per layer do you have, on average
- how many layer groups are you using?
 
I'll then include this information in the defect.
 
Thanks,
Walt

  _____  

From: mapguide-users-bounces at lists.osgeo.org
[mailto:mapguide-users-bounces at lists.osgeo.org] On Behalf Of Joel
Carranza
Sent: Monday, February 12, 2007 11:10 PM
To: MapGuide Users Mail List
Subject: Re: [mapguide-users] DWF Viewer progress bar?


Walt, 

1) I don't follow this question
2) No attribute data is available. 
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. 
4) No custom processing, this is just our map "out of the box"

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. 

Very weird, especially given that as you say, the legend is downloaded
at the beginning. 

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. 

Joel

Walt Welton-Lair wrote: 

	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
(http://www.fiddlertool.com) might let you do this.  You can then open
the DWF using a zip utility and see the individual resources.
	 
	Walt
	 
	-----Original Message----- 
	From: mapguide-users-bounces at lists.osgeo.org 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: mapguide-users-bounces at lists.osgeo.org 
		> [mailto:mapguide-users-bounces at lists.osgeo.org] 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. 
		> 
		>
http://dwf.blogs.com/beyond_the_paper/2006/09/dwf_progress_ba.html 
		> 
		> 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 
		> mapguide-users at lists.osgeo.org 
		> http://lists.osgeo.org/mailman/listinfo/mapguide-users

		> 
		> _______________________________________________ 
		> mapguide-users mailing list 
		> mapguide-users at lists.osgeo.org 
		> http://lists.osgeo.org/mailman/listinfo/mapguide-users

		> 
		> 
		> 
		> 
		>   
	
		_______________________________________________ 
		mapguide-users mailing list 
		mapguide-users at lists.osgeo.org 
		http://lists.osgeo.org/mailman/listinfo/mapguide-users 
	
	  
	
  _____  


	_______________________________________________
	mapguide-users mailing list
	mapguide-users at lists.osgeo.org
	http://lists.osgeo.org/mailman/listinfo/mapguide-users
	  

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapguide-users/attachments/20070213/ef5b0c15/attachment-0001.html


More information about the mapguide-users mailing list