[sldev] VWR-13511 : Occasional crashes in OpenJPEG

[Philippe Bossut (Merov Linden)]

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