Good questions. I've already reimplemented the one for the
LLGestureManager active list in MonoVida, which in the new
implementation it only sets a dirty flag. Later, way after login, when
the user looks at the Gesture combo box, for example, the list is then
read and sorted if the dirty flag is set. If someone never uses that
combo box, then it would never be read and sorted. This give more time
to process the requested assets and less chance to drop that info.
http://jira.dzonux.net:8080/browse/MVS
It does appear that lots of these assets are set high priority at
login, when they could be just queued up from the initial list to
download and process even after login. Might be good to set high
priority only to the ones more used more often and that are not found
in the local cache immediately after login. All other non high-priority
assets can be thrown to another thread and queued for download in idle
frames.
Personally, I rather watch the world rez-in rather than a meter display
progress on inventory loads I hardly use.
Tigro Spottystripes wrote:
I believe I understood most of what you said. The client does many
analysis on the contents of the inventory each time any new info about
it comes, so with a big inventory there is lots to do each time, and
lots of times. But your explanation raised two questions IMO,why the
client can't walk and chew bubble gum at the same time, and why it was
allowed to think it got the whole inventory when it doesn't. Actually, 3
questions, the rhird is why the client was allowed to have the login
process be so fragile while at the same time throwing heavy things into
the login process.
Dzonatas Sol escreveu:
If you look at LLGestureManager, you'll notice that it has "listeners"
that watch changes to the active list of inventory items (for gesture
in the case of LLGestureManager). When a change happens, then a
routine is called that reads the active list, sorts the items, and
builds arrays of data for later processes like combo boxes, or search
keys, and more. The problem is that it does a fresh sort every time
the list is touched. That means as the login process happens, about
the point where the progress meter reaches just beyond half way, it'll
send and receive inventory requests and sort all that data over and
over again for each special list for each item received. If you've
messed with the login process at all, you'll find that it is really
easy to timeout the login process. Most likely, if you have 30K
objects, you are well beyond the possibility of sorting those lists a
couple ten thousand times before you appear in world. This further
means that any time spent too long to sort those lists could lead to
packets being dropped. If I haven't confused you yet, then you would
realize that after you login, it could be very easy for you entire
inventory not to appear, and you'll have to refresh it (manually)
where you'll have more luck to complete the inventory download since
the local cache has already has stored many of the recently requested
assets, which means it doesn't have to request all the inventory from
the server the next time around.
Anybody, feel free to explain that easier, go ahead! =)
Tigro Spottystripes wrote:
Interesting, much more comprehensive than I expected, but can you
explain me why the client doesn't got such a thorough capability of
reading the inventory? (the total item count for my inv varies from
about 9k to 30k+ depending on my luck, regardless of how many items I
add or delete) Or does the check randomly misses things in the inventory
like the client do?
_______________________________________________
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/SLDev
Please read the policies before posting to keep unmoderated posting privileges
|
