[sldev] [VWR] The OpenJPEG lossless decode bug

Callum Lerwick seg at haxxed.com
Wed Dec 5 13:50:06 PST 2007


Okay, after finally getting into a position where I can rapidly test
changes, and after being nagged by Gigs Taggart, I finally sat down and
resolved to fix that damn lossless decode bug. Following the hint given
on VWR-2404, I traced backwards from LLImageJ2COJ::decodeImpl(), looking
for where the compressed data was coming from. After stumbling around a
twisty maze of badly abstracted code, with the help of Dale's doxygen
run, (http://doc.daleglass.net/) I found LLImageJ2C::calcDataSizeJ2C()

Yes, it is making assumptions about the compression ratio. So I tried
this:

--- linden.orig/indra/llimage/llimagej2c.cpp    2007-11-07 20:18:06.000000000 -0600
+++ linden.patched/indra/llimage/llimagej2c.cpp 2007-12-05 13:14:53.000000000 -0600
@@ -310,7 +310,7 @@
 //static
 S32 LLImageJ2C::calcDataSizeJ2C(S32 w, S32 h, S32 comp, S32 discard_level, F32 rate)
 {
-       if (rate <= 0.f) rate = .125f;
+       if (rate <= 0.f) rate = 0.5f;
        while (discard_level > 0)
        {
                if (w < 1 || h < 1)

Success! (sorta) I no longer see corrupted textures. Right now I am
staring at a perfect ant, in the SW corner of Hippotropolis.

Unfortunately, its not a complete fix. Some lossy textures seem to get
stalled during download, in particular, the map textures. I suspect my
hack is messing up the way priority is being calculated, which is
complex and uncommented. It seems if I sit and stare at the map for a
looooooong time, (~5min) it will eventually load at full res.

So it's probably is the same bug as VWR-2404, the viewer is not
downloading textures fully, then hands them off to OpenJPEG and it
barfs. I'm wondering why KDU doesn't have as much a problem, this bug
seems to be in common code.

At the risk of feeding the hostility that has been running rampant on
the list lately, note that in VWR-2404 Qarl completely ignores my albeit
not strongly worded request for what the fix was. This would be an
example of "the wall" that has been driving us nuts. The fix has been
tied up in QA hell for two months, meanwhile I can't do my own QA and
confirm if it fixes the problem with OpenJPEG.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20071205/2806ebf8/attachment.pgp


More information about the SLDev mailing list