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.
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.
