This is being entered as a BUG cos its an OBVIOUS performance booster.
Looking at World Map for first time - everything is grey and takes many minutes to download.
Leaving map and returning , say, 5 mins later - everything is grey and takes the same amount of time to download!
Instead, map data should reside in viewer after first download. Changed data only can be incrementally downloaded from the server on a performance related algorithm at Linden's discretion.
As the same map region around an AV's land ownership is far more likely to be downloaded again next session, then its data should be stored in the Viewer for the next session to use.
Also scrolling the map off screen often shows no greyness of the previously off screen regions. It appears that off screen map data is being downloaded even when not asked for.
Stop that!
(And lets fix the JIRA so that searching on "MAP and DOWNLOAD and SLOW " in SUMMARY ONLY – returns only those with all 3 words. In fact lets change it to do what all search engines do - make AND implicit not OR).
Al
New Feature
Open
Major
World Map download unnecessarily slow. Map Data is not stored in Viewer - it should be. Off screen map data should not be downloaded till needed. Home map data to persist. 
This assumption breaks down in many cases.
On the viewer this can manifest itself as
VWR-1815and VWR 2404 bugsOn the server it is a very slow download especially for maps and i have also seen other textures take this long too.
It appears that a RequestImage message is sent with a requested discard the server then fires a bunch of messages back with the image data. It appears that the server is making the same discard factor assumptions as the viewer eg that dreaded 0.125 factor so the server decides how much data to fire for a given discard level then stops when it thinks it has sent enough.
The original reporter said the map data should reside on the viewer's computer once downloaded, it does in the texture cache but due to the same bugs it gets in a pickle when recalling and we have a low resolution texture or a corrupt texture again.
If the viewer does not baulk at the data sent back either with KDU doing some black magic or patches to stop openjpeg barfing, the data will only trickle back with one additional packet every 10-15 seconds (LAZY_FLUSH_TIMEOUT) lltexturefetch.cpp which is why maps etc can take 20 minutes to download. The server clearly will only send 1 packet back for every request above what it considers the data cutoff for the given discard level.
This can also manifest itself with map textures being stuck at 128x128 for 15 minutes.
The sever needs to understand the amount of data for a given discard and not make assumptions which are incorrect in many cases.