| Age | Commit message (Collapse) | Author |
|---|
|
Checker: UNINIT_CTOR
Function: LLVOVolume::LLVOVolume(const LLUUID &, unsigned char, LLViewerRegion *)
File: /indra/newview/llvovolume.cpp
|
|
Review #83
The function LLMediaEntry::checkCandidateURL() assumes the URL passed
in at least has a scheme part (i.e. a ":"). This fixes the bounceBack
code to assure that.
|
|
their media data
|
|
|
|
http://codereview.lindenlab.com/265005/show
|
|
Rendering cost calculations didn't handle the case of a face having no image
associated with it. Added in null checks before using the pointer to the image.
Crash no longer repros.
Code reviewed by Vir.
|
|
This is because I've observed that in heavy regions, media was
not getting loaded because the queue items were stuck with the
head item at interest = 1024. This is the "default" value, which
means it probably wasn't calculated yet. This forces the
calculation.
Also cleaned up some logging in mediadataclient
|
|
data client
Conceptually reviewed by Monroe
|
|
If the object is in the selection, its interesting. Load its media data
ASAP.
Conceptually reviewed by monroe
|
|
|
|
the target object and use that fact to raise its interest level.
This is mostly a pass-off for monroe to take and run with
|
|
|
|
previous fix fixed the double-counting of texture costs. resulting ARC
was ~99 points higher for most avatars. This patch makes the cost shoot
up again, as ARC was improperly computed in 1.23 and before.
This makes the cost for an avatar increase 10 points per prim instead of
per-attachment, which is how we have documented it. Also used constants to
eliminate magic numbers and increased ARC limit from 1024 to 2048.
Will request feedback on change from BSI:STU
Code reviewed by Bigpapi
--HG--
branch : avatar-pipeline
|
|
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
|
|
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!)
|
|
|
|
functionality).
LLVOVolume::regenFaces() (specifically the calls to facep->setTexture()) breaks associations between faces and LLViewerMediaTexture objects when called on a prim with playing media.
This change adds code which recreates the associations.
|
|
Also replaced many duplicate calls to LLViewerCamera::getInstance() with local pointer.
Reviewed with Ambroff
|
|
--HG--
branch : avatar-pipeline
|
|
Fixing a but in new ARC function where textures added 5 to the ARC for each
use. Expected (and previous) behavior restored, where 5 is added to ARC for each
unique texture, regardless of how many faces it is used on.
Confirmed new ARC is 99 points higher than previous (20 for each body part), or
119 if avatar is wearing a skirt.
Will be post-reviewed before pushing
--HG--
branch : avatar-pipeline
|
|
|
|
marked as dead.
When LLMediaDataClient::QueueTimer::tick() encounters an object at the head of the queue that's dead, it will now remove that object and loop, instead of sending a request and waiting for the tick timer to fire again.
Added an isDead() function to LLMediaDataClientObject, and an additional unit test that verifies the handling of dead objects.
|
|
the dead object.
|
|
First crack at updating the rendering cost calculation for avatars to account
for the possibility of invisible avatars. Also generalized rendering cost of
attachments to be more general - added debug code to build floater
will be post-reviewed
|
|
in flight
Review #33
This change marks the current selection "not editable" if
any objects in the selection are currently "in flight" (i.e.
their media data has not been fetched yet, or is in the
process of being fetched). This involved adding API to
LLMediaDataClient to query whether an object is in the
process of being fetched (i.e. in the queue). I've added
a unit test for this new API.
|
|
|
|
LLMediaEntry::asLLSD() have a contract conflict
Review #31
So, here's what was happening, briefly:
- LLMediaEntry::setWhitelist() would be a no-op if given an LLSD that did not have a WHITELIST_KEY
- LLMediaEntry::asLLSD() would render the LLMediaEntry *without* a WHITELIST_KEY if the whitelist was empty
Therefore, when the viewer marshalled an LLMediaEntry for the server, it would send it without a WHITELIST_KEY. When the server got it, it would not erase the last value.
This is actually a workaround: it patches asLLSD() with an LLSD::emptyArray() if the key is not there. However, this should be fixed on the server: in either or both of the following ways:
1) LLMediaEntry::setWhitelist() should not be a no-op if the LLSD has no WHITELIST_KEY: it should erase the whitelist
2) LLMediaEntry::asLLSD() should render an empty whitelist in WHITELIST_KEY as an empty array
Note that both could be done and still work.
A unit test should and will be written next.
|
|
Made LLViewerMedia::updateMediaImpl() unload the impl's media plugin when the current URL goes empty.
Made LLVOVolume::syncMediaData() call removeMediaImpl() if the media data gets deleted.
|
|
|
|
|
|
This code seems to work on some objects and not on others. I suspect I'm not doing something quite right in LLVOVolume::getApproximateFaceNormal().
|
|
|
|
|
|
|
|
--HG--
branch : texture-pipeline
|
|
|
|
navigate/interact or controls "permission"
Review #27
Back when media controls (an unfortunately much-overloaded word) was called media permission (also an overloaded word), we granted "permission" for interact/navigate or controls "display" if the requestor agent had modify permissions. This decision doesn't seem to make sense, because it is a common use case to want to "disable" controls (or perhaps interaction/navigate) even for the user who created the object (i.e. who has modify permissions). This removes that check.
NOTE that this check is also made on the server, but in that case modify permissions *grants* the right to navigate in that case. Although the code is very similar, the viewer version is trying to address a use case story, whereas the other is trying to prevent a griefing vector.
|
|
|
|
Reviewed by Bao
|
|
MEDIA_PERM_INTERACT and MEDIA_PERM_CONTROL
|
|
|
|
event at all.
|
|
This required a bit of refactoring of LLMediaDataClient:
- Created LLMediaDataClientObject ABC, which now has a
concrete impl in LLVOVolume
- Created unit test with 6 tests (for now), testing
- LLObjectMediaDataClient::fetchMedia()
- LLObjectMediaDataClient::updateMedia()
- LLObjectMediaNavigateClient::navigate()
- queue ordering
- retries
- nav bounce back
- Also ensures that ref counting works properly (this is important, because
ownership is tricky with smart pointers put into queues, peeled off
into timers that fire and auto destruct, and HTTP responders that also
auto-destruct)
- Had to fix LLCurl::Responder's stub, which was not initializing
the ref count to 0, causing the ref counting tests to fail
(boy, that was hard to find!).
Reviewed by Callum
|
|
is "") if the server denies navigation
This refactors some of the bounceBack code into LLVOVolume.
It also changes an important rule: the edit panel now *will* send the
current URL to the server when you hit "OK". This change was done so
that if autoplay is on, we make sure the server gets the right data.
|
|
|
|
single reusable class
CC Review #7 (monroe)
LLMediaDataResponder and LLMediaDataFetcher were helpful classes that interacted with each other, but they were not general enough to cleanly be used for all media service interaction. This change refactors these classes into one (in fact, it is closer to a complete rewrite): LLMediaDataClient. This class has the following design points:
- You subclass from it when you want to specialize the responder, and then subclass from LLMediaDataClient::Responder if desired
- It has a few inner classes:
- LLMediaDataClient::Request, which now holds all of the data pertaining to a request, including retry counts
- LLMediaDataClient::Responder, which is now the LLHTTPClient::Responder
- LLMediaDataClient::PriorityQueue, which is now a STL priority_queue of Request objects.
- LLMediaDataClient::QueueTimer, which is the timer that fires to peel off queue items
- LLMediaDataClient::Responder::RetryTimer, which is the timer that is used when 503 errors are received.
The encapsulation of these inner classes is a lot cleaner and better reflects the scope of their responsibilities.
By and large, the logic hasn't really changed much. However, now there are two subclasses of LLMediaDataClient: one for the ObjectMedia cap and the other for the ObjectMediaNavigate cap. (I decided it was overkill to make three subclasses, one each for GET, UPDATE, and NAVIGATE, but we could still do that). LLVOVolume now instantiates both of these classes as statics (and destroys them on shutdown). They now have very simple API:
- LLObjectMediaDataClient::fetchMedia(LLVOVolume*) fetches the media for the given object
- LLObjectMediaDataClient::updateMedia(LLVOVolume*) sends an UPDATE of the media from the given object
- LLObjectMediaNavigateClient::navigate(LLVOVolume*, U8 texture_index, const std::string &url) navigates the given face (texture_index) on the given object to the given url.
|
|
svn+ssh://svn.lindenlab.com/svn/linden/branches/media-on-a-prim/moap-7
Merging branches/media-on-a-prim/moap-7 down to viewer-2.0.
|
|
fixes all of the parentheses warnings in the code.
Original patch was reviewed by merov (and others).
|
|
|
|
Self reviewed.
|
