[sldev] Crash reports analysis [http-texture builds]

[Robin Cornelius]

Rob Lanphier wrote:
> Reviving old discussion.....

Copying in directly the two resident openjpeg experts, esp as Callum is
not so active in SL now but still very involved in openjpeg

>>   
> Well....this seems like a concerning thing to let just lay around. I've
> got a few questions about this:
> 1. The SLDev Viewer should be using KDU by default. Is there some
> functionality (e.g. the new map) that uses OpenJPEG by default, even if
> KDU is available?

No, but some of us don't use KDU *at all* because it does not support
64bit and because its not opensource. Is it even automaticly downloaded
any more for the build? There were issues where at one point it did not
download even on windows.

Regardless of KDU, Openjpeg needs supporting, it would reflect badly on
LL to not support it and say yes this is opensource, and we have this
shiny open source branch, but you have to use this propriety dependency

> 2. Is there something in JIRA about this particular issue already?

I don't recall such an issue yet.

http://jira.secondlife.com/browse/VWR-2342 was the meta for openjpeg but
that seems to have a couple missing.

> 3. Since this bug isn't fixed in OpenJPEG 1.3, but the release timeline
> for OpenJPEG 2.0 doesn't look clear, what would be the odds of
> convincing the OpenJPEG team to ship an OpenJPEG 1.3.1. We've got a
> strong preference to stick with releases rather than svn snapshots.

2.0 does not look likely soon. The people behind openjpeg are quite
busy. Dzontas has got 2.0 working with secondlife but there are
remaining issues mainly to do with progressive downloads i believe. May
be he can comment further on exactly what is wrong.

> 4. If an OpenJPEG 1.3.1 isn't in the cards, it seems like we should suck
> it up and patch our OpenJPEG. Right?

There was talk of a 1.3.1 and in fact SVN contains some updates that use
the opj_calloc instead of the opj_malloc that fixes this specific issue.
But again i think the openjpeg guys have just been too busy to push
either 2.0 or 1.3.1 forward.

Debian has 1.3-5 and the debian git has 1.3-6 which includes the above
fix, instead of *yet another* fork maybe you could track the Debian
release (which i am maintainer for) and we can try to keep this
backporting of fixes sane and uniform across multiple
distributions/platforms etc.

> 5. Is the currently shipping SLDev Viewer build still on 1.2?

I believe so, although Tofu might know better but looks like 1.3 is
hitting 1.23

http://jira.secondlife.com/browse/VWR-4041

1.2 was a show stopper for 64bit systems

> 
> Some of these I'll be able to research myself, but I also know there are
> many of you who know this off the tops of your respective heads.

I would also like to toss in the mix that openjpeg 1.2, 1.3 or even back
  to 0.97 has issues with encoding alpha and ends up with the entire
alpha channel set to 128 v2.0 fixes this issue, but i believe there is
no clear backport to 1.3 for this problem currently.


Robin

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 260 bytes
Desc: OpenPGP digital signature
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20090514/8f3a0c4b/attachment.pgp