From 248427b8f956f3e879aeda9179b0479a6d778ab7 Mon Sep 17 00:00:00 2001 From: Rick Pasetto Date: Thu, 10 Dec 2009 14:21:48 -0800 Subject: PARTIAL DEV-43869: LLMediaDataClient now uses two queues This is a fairly major change that addresses the issue of an object with constantly-updating media. Before, that object would be put into our single queue and sorted to a particular spot, and since it continuously updates, it would "always be there". That means that nothing "behind" it would ever get serviced. This change introduces two queues for each MDC: one is the same "sorted" queue as before, and the other is unsorted, and "round-robins". New objects go into the sorted queue, objects whose media we already know about get put into the unsorted queue. The two queues are interleaved when serviced (one then the other is serviced -- if one is empty we try the other -- until they are both drained). The round-robin queue works a little differently: after an item is fetched from that queue (remember this would be an item we already know about), that request is marked and put back at the end of the queue. If that object gets a UDP update while in the queue, that mark is "cleared". When it gets to the front of the queue again, if it still marked, it is thrown away. If it is not marked, it is fetched, and again marked and put at the end. This makes the queue self-limiting in how big it can get. I have also made some other changes: - The sorting comparator now just delegates to the object for its "interest" calculation. A higher value = more interesting. LLVOVolume now uses its PixelArea for its "interest" calculation, which seems apparently better (the prior distance calculation was wrong anyway). - The score is cached before the sort operation is performed, so that it won't be expensive to sort - Now, the media version that is fetched is saved in the LLVOVolume, and we do not update if it is not newer (this is not very useful...yet.) - I've introduced hard limits (settable by debug settings) on the size of the queues. The sorted queue will be culled (after sort) to that count. NOTE: this will probably get removed in a later checkin, as I've already gotten feedback that this is not desirable - I've reorganized LLMediaDataClient so it makes more sense. - I've made the request object a little smaller, so the queue won't take up so much memory (more work could be done here) - Added a unit test for the two-queue case (though more tests are needed!) --- indra/newview/app_settings/settings.xml | 22 ++++++++++++++++++++++ 1 file changed, 22 insertions(+) (limited to 'indra/newview/app_settings') diff --git a/indra/newview/app_settings/settings.xml b/indra/newview/app_settings/settings.xml index c43032a3cf..19efeed7f0 100644 --- a/indra/newview/app_settings/settings.xml +++ b/indra/newview/app_settings/settings.xml @@ -5504,6 +5504,28 @@ F32 Value 5.0 + + PrimMediaMaxSortedQueueSize + + Comment + Maximum number of objects the viewer will load media for initially + Persist + 1 + Type + U32 + Value + 120 + + PrimMediaMaxRoundRobinQueueSize + + Comment + Maximum number of objects the viewer will continuously update media for + Persist + 1 + Type + U32 + Value + 15 ProbeHardwareOnStartup -- cgit v1.2.3 From 2d01d763d558a373b356ea445ddb3801e36ae457 Mon Sep 17 00:00:00 2001 From: Rick Pasetto Date: Thu, 10 Dec 2009 17:03:40 -0800 Subject: PARTIAL DEV-43869 - add "isInterestingEnough()" to the queue calculation This change bumps the queue sizes way up, because we think that the "isInterestingEnough()" call will prevent loading more media data than we think is necessary. Still need to implement it in LLVOVolume, though --- indra/newview/app_settings/settings.xml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'indra/newview/app_settings') diff --git a/indra/newview/app_settings/settings.xml b/indra/newview/app_settings/settings.xml index 19efeed7f0..9ef74364ac 100644 --- a/indra/newview/app_settings/settings.xml +++ b/indra/newview/app_settings/settings.xml @@ -5514,7 +5514,7 @@ Type U32 Value - 120 + 100000 PrimMediaMaxRoundRobinQueueSize @@ -5525,7 +5525,7 @@ Type U32 Value - 15 + 100000 ProbeHardwareOnStartup -- cgit v1.2.3