Couldn't the map be cached?

Every time I open the big map -- even if I had it open 10 seconds earlier -- the entire map has to build up square by square. It can take 20-30 seconds for the entire map to fill in. And if I then close it, and immediately re-open it -- it starts all over again.

The terrain of 2L as shown in the map doesn't really change that much. Why couldn't the basic information be downloaded just once, cached, and be re-used each time the map opens?

I don't know to what extent the zoomed-in map really reflects the building status of each square meter, but even if it does reflect the status of structures, those change very slowly too, as a percentage of land area. Frankly, I don't care if the map is exactly to the meter accurate but it could be kept that way by downloading like 1% of the map pixels as a delta, once, on log-in.

The pink event-stars are dynamic info, but they, properly encoded, couldn't amount to 2K of data and don't need to be accurate to the second, only to the nearest hour. The green people-poker-chips are volatile on a 5-minute basis, but again that can be encoded at a byte per terrain, and again, only changes need be sent.

Just a little smarts -- standard software engineering -- would make the map much more responsive and useful.

medlar, being a constant explorer, I hear ya.

It would be nice to have a "Freeze Map" button that does just that, and statically displays the map until you unfreeze it -- or if you forget, until several days later.

The little green poker chip people you mentioned really arnt that accurate anyway. Have you noticed they are always about 25-50m off? I dont know if this does it for you, but often, when I track my friends (not a phyco ) itll stuff their red circle into the corner, and I dont know where they are, especially when they are at an event. Thats actually pretty much all I use the map for... is to make sure im not interupting something by barging in with a new annoying IM session saying "Whats up?" or "How you doing, send me a TP!"

I think the Linden model for this is, "We already use much more bandwidth on other things and there is no need to be efficient on things like the map or patches." I agree it would be nice to see more efficient software engineering in SL.

since the map images only change if something new gets built or demolished i agree it should be cached. just have it check when you open whether the image you have for a sim is older than the one they have on the server end and only download if it's different. then i will be happy for at least 1 minute. promise

The map has to be cached somewhere, because a sim can be erased, yet not reflected on the map for half-a-day. I think the map loads pretty quickly, and if I toggle between the different modes, the longest load may be 5-seconds... except for sims with "NO IMAGE."

I wonder what is the average cache-size for SL users? If your drive is nearly full and the file system is a mess (fragmented or full of disk-slowing spyware), cached elements could rez slower than streamed elements.

Let me semi-hijack this thread and remind LL that we really ought to have a PER-SIM CACHE.
Or something like that.
1 gig is NOT ENOUGH. Hard drive sizes are getting ridiculous, while bandwidth is still freaking expensive. At least for us unamerican users who have metered bandwidth.
Metered/capped downloads are the norm in just about every country in the world.
SL now has users from SEVENTY countries.

no doubt. i'd give sl 20 gig of cache if i could. mine's set to 1 gig and i can be hanging around the house then teleport some place and when i come back my whole house downloads again. you can't tell me hanging out in a field somewhere for 5 minutes filled up my cache again. or is it set up so things i own are low priority in the cache?

I think it was decided that it becomes increasingly slow to SEARCH the cache if it's too big.

Perhaps a solution would be to let people cache plots of their choosing.

I think Hiro said what I was trying to say... the cache actually becomes slower than the download at some point.

Hiro, please review your Data Structures class material, and tell me which can be accessed in O(1), O(N), O(N^2) etc.

Now, I dont know about you, but a cache is usually implemented with a hash table, and IIRC, hash tables can be accessed in constant time, which means that no matter how large the dataset, in _theory_ the time to access any random element should remain the same.
Of course in _reality_ 1 gig won't fit in the average RAM and it's a lot faster to access the innermost tracks of a hard drive than the outermost, plus there's always the possibility of fragmentation so... YMMV!

ANYWAY! Geting back on topic
Keeping the exact same cache file structure and naming each file after the simulator you were in at the time of asset download should make each file immediately adressable without any performance penalty.
I think it was Azelda who first suggested it... Yup, it's here:

/111/f7/13898/1.html

Also:

/13/55/24002/1.html

The main advantage of a per-sim cache is that you get to fly around without bumping useful stuff out of it. Actually, I spend my whole day in a mostly empty hidden island sim with 3000 prims where I get 3-4 people, tops. Most of it uses what, 5 different textures?
How the heck is this making me download over 100 megs in a day?