I had openjpeg 1.5 long ago for some time, the 32bit version wasn't all that better... it was... unreliable.
2017-01-17 18:09 GMT+01:00 Nicky Perian <nickyper...@gmail.com>: > >>Please forgive me if this should already be on my plate, but I don't > >>recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load > >>texture files that are correctly handled by 1.5.0? > > Yes. > openjpeg-1.5.1 has so many textures marked as over-sized and unavailable > that the viewer is unusable. This came about with viewer64 as the default > viewer is still on openjpeg-1.4.0. I had seen the same texture missing > message once while using Project Alex Ivy viewer and filed a jira on that > instance at https://jira.secondlife.com/browse/BUG-41228 . I am making a > wild guess, but I think there is a possible CDN delivery issue that > openjpeg-1.5.1 may be prone to more so than openjpeg-1.5.0 or KDU. > > I had not known of openjpeg-1.5.0 every being supplied in a viewer or I > would have certainly looked for it. > > > > > On Tue, Jan 17, 2017 at 9:14 AM, Cinder Roxley <cin...@alchemyviewer.org> > wrote: > >> We’ve had OpenJPEG 1.5.1 running solidly on Alchemy for years now. I can >> put together some patches to get it working. >> >> -- >> Cinder Roxley >> Sent with Airmail >> >> On January 17, 2017 at 9:03:11 AM, Nat Goodspeed (n...@lindenlab.com) >> wrote: >> >> Nat Goodspeed <n...@lindenlab.com> erian <nickyper...@gmail.com> wrote: >> >> > https://bitbucket.org/lindenlab/p64_3p-openjpeg/pull-requests/2 >> > >> > Please take this in and then provide for the updated archives in the >> viewer. I also received a report that the missing texture issue is in macOS >> when using openjpeg-1.5.1. >> >> There are admittedly painful aspects to the two-step autobuild >> mechanism: (1) rebuild the 3p package and (2) update every consumer. >> >> However, one of the benefits of that approach is that we can adjust >> the version of a given 3p package consumed by (e.g.) the viewer >> without actually having to revert the 3p repository source. We can >> just change back the package URL specified in the viewer's >> autobuild.xml. >> >> > Or, if the problem with 1.5.1 is easily corrected.... >> >> Please forgive me if this should already be on my plate, but I don't >> recall a Jira about the openjpeg 1.5.1 issues? Does 1.5.1 fail to load >> texture files that are correctly handled by 1.5.0? >> >> I think Cinder has a point: if we can move forward with 1.5.1, we should. >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> >> >> _______________________________________________ >> Policies and (un)subscribe information available here: >> http://wiki.secondlife.com/wiki/OpenSource-Dev >> Please read the policies before posting to keep unmoderated posting >> privileges >> > > > _______________________________________________ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges