[opensource-dev] Review Request: STORM-1001: Viewer needlessly hits the "ObjectMedia" cap with thousands of requests

[Kitty Barnett]

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/162/
-----------------------------------------------------------

Review request for Viewer.


Summary
-------

S32 LLTextureEntry::setMediaTexGen(U8 media) would appear to be the root cause of the bug:

The header file suggests that:

// The Media Tex Gen values are bits in a bit field:
// +----------+
// | .....TTM | M = Media Flags (web page), T = LLTextureEntry::eTexGen, . = unused
// | 76543210 |
// +----------+
const S32 TEM_MEDIA_MASK		= 0x01;
const S32 TEM_TEX_GEN_MASK		= 0x06;

and while LLTextureEntry::setTexGen() and LLTextureEntry::setMediaFlags() each properly mask off the supplied parameter with their respective bit mask, setMediaTexGen() will always return TEM_CHANGE_MEDIA even if only texgen has changed while the media flag hasn't (causing LLVOVolume::processUpdateMessage() to queue a request to the cap when it shouldn't).

Changing it to:

S32 LLTextureEntry::setMediaTexGen(U8 media)
{
	S32 result = setTexGen(media & TEM_TEX_GEN_MASK);
	result |= setMediaFlags(media & TEM_MEDIA_MASK);
	return result;
}

appears to resolve the issue completely (the cap isn't hit unless an object nearby has media on it, or changes its URL)


This addresses bug STORM-1001.
    http://jira.secondlife.com/browse/STORM-1001


Diffs
-----

  indra/llprimitive/lltextureentry.cpp UNKNOWN 

Diff: http://codereview.secondlife.com/r/162/diff


Testing
-------


Thanks,

Kitty

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20110222/604b5b7c/attachment.htm