[sldev] VWR-13511 : Occasional crashes in OpenJPEG
Philippe Bossut (Merov Linden)
merov at lindenlab.com
Sun May 24 22:13:03 PDT 2009
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,
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
I'll attach a patch to the JIRA so others can try and improve the way
I measured things.
More information about the SLDev