STORM-1001: Viewer needlessly hits the "ObjectMedia" cap with thousands of requests
Review Request #162 - Created Feb. 22, 2011 and submitted
| Kitty Barnett | Reviewers | ||
| viewer | |||
| STORM-1001 | |||
| None | viewer-development | ||
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)
Expand AllPosted (Feb. 26, 2011, 2:12 p.m.)
-
indra/llprimitive/lltextureentry.cpp (Diff revision 1) -
Is this creation/destruction of mMediaEntry taken care off elsewhere already?
Posted (March 1, 2011, 10:22 p.m.)
-
indra/llprimitive/lltextureentry.cpp (Diff revision 1) -
Looks like you need to add creation/deletion of mMediaEntry if the TEM_MEDIA_MASK bit flipped.
This change looks good to me. It looks cleaner and more correct.
Other reviews