[sldev] Re: OpenJPEG usuable now

[Todd T. Fries]

Congratulations!  I can't wait to try out this speed improvement myself.

Waiting with baited breath for the patches.. ;-)

Thanks,
-- 
Todd Fries .. todd at fries.net

 _____________________________________________
|                                             \  1.636.410.0632 (voice)
| Free Daemon Consulting, LLC                 \  1.405.227.9094 (voice)
| http://FreeDaemonConsulting.com             \  1.866.792.3418 (FAX)
| "..in support of free software solutions."  \          250797 (FWD)
|                                             \
 \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\
                                                 
              37E7 D3EB 74D0 8D66 A68D  B866 0326 204E 3F42 004A
                        http://todd.fries.net/pgp.txt

Penned by David D. Fries on 20070209  1:35.01, we have:
| I'm a bit excited.
| 
| I have some patches that I'm working on, but I was just able to fly a
| loop around a three region area just now with them and it seemed
| comparable to the binary client.  This is with OpenJPEG and the first
| look source client on a Linux dual core 64 bit AMD machine.  Good
| enough that I'm going to have to fly around it again with the binary
| version and compare.  Any suggestions on how to compare the
| performance between them?  My qualitative experience tonight says that
| it is good enough to run with.  Up until tonight it was like pulling
| teeth using OpenJPEG, so bad, now it looks good.
| 
| I hacked OpenJPEG to have an opj_meta_decode that would only decode
| enough to get the size and number of channels.  That's all getMetadata
| used anyway.  That patch needs to be cleaned up and submitted to
| OpenJPEG.  But here are the results.
| 
| A full decode can take anywhere on the order of .015 to .5 seconds
| (though I've seen 1.5 seconds before).  Currently Second Life does a
| full decode, saves the image size and channels, then tosses the image.
| This OpenJPEG meta decode just gets enough header decoded to get at
| the image sizes, and it AVERAGED at .000076 seconds that's with 6200
| samples and all but two under 1 millisecond.  That's a total of .474
| seconds spent in OpenJPEG getMetadata decode, or about the time it
| takes to decode a large image.
| 
| There is a function, LLImageJ2C::validate that calls
| mImpl->getMetadata in llimage/llimagej2c.cpp, my question is how much
| validation is required to be done to the image?  I only see that
| function being called by LLViewerImageList::createUploadFile.
| Seriously though, does it just need to find out if it has a jpeg
| header without looking at any data?  In that case the meta decode
| should work.
| 
| The last piece of the puzzle was based on a patch on jira by Hiro
| Sommambulist, VWR-66.  Without that patch textures decoded at say a
| 1/8 resolution would only take up 1/8 of the size leaving the rest
| blank and grow from there until it was fully decoded.  Some of his
| math didn't make sense to me, but it was enough to point me in the
| right direction.  I have some cleanup work to do on that patch as
| well.
| 
| Of course it wouldn't have been possible without the first look viewer
| FL-1.13.3.57679 doing the actual jpeg2000 decoding in another thread.
| I wasn't going to go as far as time slicing the decoding like the
| proprietary decoder does.
| 
| In my previous e-mail where things were still gray after an hour at
| the International Spaceflight Museum?  It was good in under a minute.
| 
| -- 
| David Fries <david at fries.net>
| http://fries.net/~david/ (PGP encryption key available)