From: Alan Webb <alan_webb@us.ibm.com>

  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.

0 files changed, 0 insertions, 0 deletions