| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
| |
* Fixed the incorrect "out of memory?" exception messages and replaced them with useful information
* Cleaned up J2KImage and LLImageManager to conform to coding conventions
|
|
|
|
| |
image packet crashes Hippo without a message.
|
|
|
|
| |
packet queue, rather than a timer
|
|
|
|
|
| |
* Rewrote the logic in J2KImage.RunUpdate()
* Added a default avatar texture (I made it myself)
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
LayerInfo.End values and creating guessed default layer boundaries on failed decodes Changed a noisy J2K decode log message from Info to Debug Replacing openjpeg-dotnet decoding with managed CSJ2K decoding. Should be much more reliable, faster, and use less memory
* Re-added openjpeg-dotnet files since they are used elsewhere in OpenSim * Updated prebuild.xml with a reference to CSJ2K
* Renamed IJ2KDecoder and J2KDecoder member names to follow standard naming conventions * Removed j2kDecodeCache cruft and replaced it with the OpenSim cache system * Rewrote the default layer boundary algorithm to use percentages instead of an exponent * Switched from an infinite in-memory cache to an expiring cache (10 minute timeout) * Slightly quieted logging errors for failed texture decodes
|
|
|
|
| |
them later if the client asks for them again. Needs more testing in texture-rich sims.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change moves texture send processing out of the main
packet processing loop and moves it to a timer based
processing cycle.
Texture packets are sent to the client consistently over
time. The timer is discontinued whenever there are no
textures to transmit.
The behavior of the texture sending mechanism is controlled
by three variables in the LLCLient section of the config
file:
[1] TextureRequestRate (mS) determines how many times per second
texture send processing will occur. The default is 100mS.
[2] TextureSendLimit determines how many different textures
will be considered on each cycle. Textures are selected
by priority. The old mechanism specified a value of 10 for
this parameter and this is the default
[3] TextureDataLimit determines how many packets will be sent for
each of the selected textures. The old mechanism specified a
value of 5, so this is the default.
So the net effect is that TextureSendLimit*TextureDataLimit
packets will be sent every TextureRequestRate mS.
Once we have gotten a reasonable feeling for how these parameters
affect overall processing, it would be nice to autonmically manage
these values using information about the current status of the
region and network.
Note that this also resolves the pathologcal problem that
previously existed which was that a seated avatar generated very
few in-bound packets (theoretically) and would therefore be the
least able to retrieve the images being displayed by a
projector script.
|
|
|
|
| |
LICENSE.txt.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
-- please see the example. Affects region servers only.
This may break a lot of things, but it needs to go in. It was tested in standalone and the UCI grid, but it needs a lot more testing.
Known problems:
* HG asset transfers are borked for now
* missing texture is missing
* 3 unit tests commented out for now
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Following feedback from 0003440, i've made some changes to the new texture pipeline to optimise
performance. The changes are:
- Fixed a math issue where a small percentage of images with a certain size (on the packet boundary) would not have their final data delivered. This issue has been present since pre- 0003440
- It was suggested that a discardlevel of -1 and a prioriy of 0 meant to abandon the transfer, this is incorrect and caused some textures to clog.
- The texture throttle blocking queue is now only filled in relation to the actual throttle amount.. i.e, on a connection throttled to 300k, only twenty packets will be placed in the queue at a time, on a larger connection it will be much more. This is to balance responsiveness to requests and speed, and to minimise wasted packets.
- The engine now keeps track of the number of pending textures, and the stack will not be walked if there's no textures pending, saving CPU. Textures are only considered "pending" when they've already been decoded.
- As part of the above, some textures may receive twice as much data per cycle if the number of pending textures is below the cycle threshold, this should prevent loading from slowing down when there are fewer textures in the queue.
|
| |
|
| |
|
|
|
|
|
| |
option at this point is going to give us a NullReferenceException
|
|
|
|
|
| |
probably just makes the decoder break somewhere else.
|
|
files
|