Hi guys, I've been digging through this problem and here are some data point and a plan of what we're intending to do: - Bundling kdu: we identified that, though we thought we were bundling the kdu libs with the snowglobe executables, we actually were not doing so because of a build script issue. CG identified the exact problem and will be fixing this shortly. This by itself will be "fixing" that bug for users downloading the builds. - OpenJPEG calls in the viewer: Dzonatas and Robin mentioned during the last Hippo meeting that there was one bug in the viewer wrt the use of the lib that we needed to fix (at least, that's what I understood). I'm all for making the fix (even if we'll be bundling kdu with the build, some of us prefer or need to run with OpenJPEG). I'd appreciate if someone would provide a patch that can be applied to the viewer code (or Robin can actually commit something). - OpenJPEG lib: Dzonatas provided some pointers to openjpeg patches in the JIRA but I don't really have the bandwidth right now to do this. Would someone volunteer to do whatever needs to be done on snowglobe to update OpenJPEG lib? - Performance: OpenJPEG vs KDU: I was curious to know what was the true difference between the 2 libraries wrt to decoding textures. I tried several ways of tracking this (which is tricky now with the new thread mechanism) and I eventually settled by tracking the pure decoding speed, adding time accumulation (and other measures) right when the library was called. I timed the use of openjpeg and kdu, verifying that dropping the kdu libs in the right place was enough to get it dynamically loaded and used by llimagej2c. Here's a selected output after using the viewer for a while with both libs:
2009-05-24T22:28:20Z INFO: init: J2C Engine is: OpenJPEG: 1.3.0, Runtime: 1.3.0 [...] 2009-05-24T22:32:44Z INFO: decode: Image decoding: completed blocks = 1460, partial block calls = 0, total decoded = 6.50681 MBytes 2009-05-24T22:32:44Z INFO: decode: speed = 0.238522 Mbytes/sec, or = 0.687382 Mpixels/sec 2009-05-25T03:49:51Z INFO: init: J2C Engine is: KDU [...] 2009-05-25T03:52:44Z INFO: decode: Image decoding: completed blocks = 1930, partial block calls = 0, total decoded = 6.49914 MBytes 2009-05-25T03:52:44Z INFO: decode: speed = 0.796175 Mbytes/sec, or = 2.95891 Mpixels/sec KDU is flat out 3 times faster to decode than OpenJPEG. The ratio is consistent throughout the whole session. Don't be too shocked about the decoding speed: this is *not* throughput of textures in the viewer. The data measures only the speed of decoding blocks of compressed images, making complete abstraction of network activity, object handling, etc... all things that are anyway identical in the 2 cases. The KDU viewer doesn't feel 3 times faster because, deep down, texture decoding is not the limiting factor that drive the perceived performance of the viewer. Still, in super texture heavy regions, I suppose this could make a difference. I'll attach a patch to the JIRA so others can try and improve the way I measured things. Cheers, - Merov _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
