| Age | Commit message (Collapse) | Author |
|---|
|
|
|
for EXT-5550: Viewer locks up consistently on the same sim.
|
|
|
|
builds.
Adding a debug watch to LLCurlRequest to avoid invalidating iterator on processing posts.
Mesh bulk uploading rewrite work in progress.
404 icons for mesh assets.
|
|
|
|
Checker: REVERSE_INULL
Function: LLVolumeGeometryManager::rebuildMesh(LLSpatialGroup *)
File: /indra/newview/llvovolume.cpp
|
|
|
|
|
|
their backout next to restore them. I hope. Sheesh.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
-- Further instrumentation of idle update
-- Removed mActiveQ from LLPipeline, instead making calm objects static during LLVOVolume::idleUpdate
-- Further instrumentation of flexible object update
-- Converted LLDynamicArray and LLMap members of LLViewerObjectList to stl counterparts
-- Increased number of update bins in LLViewerObjectList from 16 to 128 (objects will be processed every 128 frames instead of every 16, or ~ 90% fewer objects processed per frame)
-- Removed unused "renderObjectsForSelect" code.
-- Reenabled LOD updates for objects further than 24m from camera
|
|
guaranteed, duh.
|
|
|
|
perhaps make the UI hurt less.
|
|
|
|
|
|
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.
|
|
U indra/llui/lluictrlfactory.cpp
U indra/newview/llinventorybridge.cpp
U indra/newview/llviewertexture.cpp
U indra/newview/llviewertexture.h
|
|
|
|
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!)
|
|
|
|
|
