[sldev] Jpeg2000 codec optimization

[Stefan Westerfeld]

   Hi!

I'd really like to see the open source client being completely open
source (as some problems that come from closed source software are there
even if only a small peace of code remains closed). Now effectively, it
depends on two things:

 - closed source jpeg2000 lib (because otherwise the performance is
   unacceptable)
 - closed source fmod music lib

I wanted to have a look into the jpeg2000 thing. Now, my first thoughts
were something along the lines that I could identify one or two
functions in the image decoder that produce the main performance issues,
understand what they do, and replace them (possibly using special multi
media instructions like SSE). It should have been a small fun hacking
thing, which could be completed in a reasonable time frame... but so far
I failed, because it is not that simple.

So here is what I did figure out so far:

* SIMD could be helpful

Using 'nm' on the proprietary code for jpeg decoding
(linden/libraries/i686-linux/lib_release_client/libkdu*) reveals: there
are implementations of the transforms used in Jpeg2000 as SIMD code, and
there are other SIMD functions.

* the Jpeg2000 standard is huge, so I suggest optimizing a special case

I read some of the "official" Jpeg2000 info, and that thing can do a
lot. My opinion is that it is probably impossible to just speed things
up by optimizing "the library that decodes". Rather it will only be
possible to take those cases that typically occur, and optimize these.

What would be ideal is a if there would be two things:
 - one (or a few) sample image that are typical for what needs to be
   decoded
 - a standalone test app that decodes, measures performance and compares
   the expected result with the actual result (this would help to see
   if a certain optimiyation step messed up the decoder)

Of course this is only helpful if SL can constrain its use of the
Jpeg2000 standard

* the openjpeg implementation may not be the best open source
choice available for the task

For instance, when browsing the doxygen docs of openjpeg
(http://www.openjpeg.org/libdoc/modules.html), I found a routine to "get
1 bit" from the stream. Now I don't know if it ever gets called, but if
it does (while decoding images), thats usually a performance problem (can
of course be masked by even worse problems), because you can always
decode a few symbols at once (at least that was the case when I
optimized some mp3 decoder).

All in all, if such things are not optimized, then that may indicate
that the authors do not care for speed but for readability only. An
alternative to the openjpeg library may be JasPer
(http://www.ece.uvic.ca/~mdadams/jasper/). Maybe just using this library
(which does for used in real world projects) could speed things up.

* I found a FIXME in the code, but cannot estimate its effect on
performance

-> from linden/indra/llimagej2coj/llimagej2coj.cpp


BOOL LLImageJ2COJ::getMetadata(LLImageJ2C &base)
{
    //
    // FIXME: We get metadata by decoding the ENTIRE image.
    //
    ...
}

Now of course if that gets called a lot, it would explain why the closed
source library is fast (which may handle this different), where openjpeg
is not.

    Cu... Stefan
-- 
Stefan Westerfeld, Hamburg/Germany, http://space.twc.de/~stefan