Re: [opensource-dev] Does writing to llerrs make the viewer crash ?
The random crash reported by Marine was VWR-24359. https://jira.secondlife.com/browse/VWR-24359 (There was a typo in the original post; two digits were transposed.) Sheet Spotter -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Marine Kelley Sent: December 31, 2010 4:43 AM To: opensource-dev@lists.secondlife.com Subject: [opensource-dev] Does writing to llerrs make the viewer crash ? [...] I have just filed a JIRA (VWR-23459) about a random crash that would occur in the rendering pipeline [...] ___ 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
Re: [opensource-dev] Attachments from stale group notices do not open
Opening attachments from a stale group notice has been failing for a year or more. https://jira.secondlife.com/browse/VWR-18240 There are many related issues and duplicates. The problem reliably occurs with the production viewer when trying to open a group notice that was received hours ago. The workaround is to open the group info. The attachment can then be opened from the list of group notices. Sheet Spotter -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Opensource Obscure Sent: February 21, 2011 3:04 AM To: Kadah Coba Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Extended Groups broken? This happened to me multiple times yesterday while I was on a TPV (Kirstens last release). Please tell the list if you find or file an appropriate JIRA issue about this so that I can add my feedback. Opensource Obscure On Mon, Feb 21, 2011 at 08:38, Kadah Coba wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Thanks Soft, I was just noticing this issue this morning. > > Could it have any relation to a problem I've been getting for over a > week with attachments on group notices never getting to my inventory > when I try to open then? I'm trying to test it but I cannot get it to > repro on purpose so I can file a jira on it. ___ 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
Re: [opensource-dev] New HTTP Library & Project Viewer
Does increasing the HTTP connection limit also increase the burden on the server and network? Increasing the HTTP connection limit on one client might improve the experience for one person. It might also diminish the experience for everyone else on the same server. Sheet Spotter -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Henri Beauchamp Sent: July 29, 2012 9:23 AM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] New HTTP Library & Project Viewer [...] FYI, early HTTP fetches code was allowing up to 32 connections already, then it was lowered to 8, then raised back up to 16, and I since lost track of what maximum is currently hardcoded in LL's viewer... That's why I made it a configurable setting: if you start seeing timeouts or "busy" replies from the server in your viewer log, then you can still lower the setting. The default in the Cool VL Viewer is 16, but I have always used 32 myself and never came accross any issue, including in over-crowded sims (and I can enjoy a very fast rezzing experience): of course, you could argue that this is because everyone else in the sim is limited to 8 connections... And you could be right (hard to say: only LL could...). [...] ___ 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
[opensource-dev] Build problems with Snowglobe 2 source
After commenting out the entire "if (LL_TESTS)" section at the bottom of
"indra/newview/CMakeLists.txt" the linker still had unresolved symbols.
It's my guess that "llcapabilitylistener.cpp" should be added to the
"CMakeLists.txt" section that starts with "set(viewer_SOURCE_FILES".
Manually adding the "llcapabilitylistener.cpp" source file to the VS2005
project allowed me to compile and run again, but there are still some build
issues. The "package" project produces the following output:
1>Processing ../win_crash_logger/RelWithDebInfo/windows-crash-logger.exe =>
win_crash_logger.exe ... 1 files
1>Processing ../win_updater/RelWithDebInfo/windows-updater.exe =>
updater.exe ... 1 files
1>Traceback (most recent call last):
1> File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line
999, in
1>main()
1> File
"C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p
y", line 237, in main
1>wm.do(*args['actions'])
1> File
"C:/SLSource/SnowglobeV2/indra/newview\../lib/python/indra/util\llmanifest.p
y", line 664, in do
1>method()
1> File "C:/SLSource/SnowglobeV2/indra/newview/viewer_manifest.py", line
563, in package_finish
1>self.run_command('"' + proper_windows_path(NSIS_path) + '" ' +
self.dst_path_of(tempfile))
1>TypeError: cannot concatenate 'str' and 'NoneType' objects
1>Project : error PRJ0019: A tool returned an error code from "Generating
RelWithDebInfo/touched.bat"
I guess it's possible this build problem is self inflicted by the edits I
made to "CMakeLists.txt".
Sheet Spotter
-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Matrice64
Sent: February 24, 2010 9:49 AM
To: Argent Stonecutter
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] Snowglobe 2 update
Yeah I commented out everything in the if (test) part of the
CMakeLists.txt towards the bottom and it worked out for me
On Wed, Feb 24, 2010 at 6:11 AM, Argent Stonecutter
wrote:
> On 2010-02-24, at 02:26, Thomas Shikami wrote:
>> SOCKS5 is usually used by griefers to mask the IP address.
>
> SOCKS5 is the only way to connect if you are behind a reasonably
> secure corporate firewall.
>
> SL is completely out of the question for business use without SOCKS5
> support, even for the kind of "3d corporate website" model that LL is
> pushing.
>
> ___
> 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
[opensource-dev] Request for clarification on mailing list guidelines
It was my understanding that [opensource-dev] is the place to open discussion on issues of interest to all developers, but that detailed discussions were expected to occur in other venues, like JIRA. The policies and guidelines for this mailing list can be found here: http://wiki.secondlife.com/wiki/OpenSource-Dev I want to draw attention to one particular guideline. If a topic generates more than five replies in less than 24 hours, it's time to redirect that conversation to one of our other tools, either the wiki, the bug tracker, or a thread in the appropriate forum. There are a few discussions occurring in [opensource-dev] which have been occurring for a considerable time. These discussions each have a JIRA entry that deals with the specific issue. The JIRA provides an open forum for the public discussion of important issues. All interested parties are able to engage in a full, open discussion of every aspect of each issue. Participants in the discussion can "watch" the JIRA issue, which will promptly inform them via email of any additions or changes. Supporters of the JIRA issue can vote for the issue, with higher voted issues carrying more weight. The ongoing discussions of some issues are creating a large volume of activity that may not be of interest to all [opensource-dev] participants. The guidelines for this mailing list encourage moving theses discussions to JIRA. Are these lengthy discussions encouraged to continue in [opensource-dev] or in other venues, such as JIRA? Sheet Spotter ___ 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
[opensource-dev] Compiler optimizations on Viewer and LLKDU
1. Are there any plans to enable higher levels of compiler optimizations for the viewer? For example, Streaming SIMD Extensions (SSE, SSE2, and SSE3) are not enabled. SSE was introduced in Pentium III processors in 1999. SSE was first added to AMD processors in the Athlon XP and Duron, both in 2001. The minimum requirements for the viewer are stated as: "800 MHz Pentium III or Athlon, or better". http://secondlife.com/support/system-requirements/ 2. Also, would the LLKDU library benefit from higher levels of compiler optimizations? Anyone can compile the viewer with higher levels of optimization using the publicly available source code. However, the source code for the LLKDU library is not publicly available. Only LL could compile LLKDU with higher levels of optimization. 3. Would LL consider providing a compiled version of the LLKDU library with higher levels of optimization? Taking advantage of higher levels of compiler optimization may improve the experience for people running low to mid range equipment. My interest is in improving the experience for residents using lower grade equipment, not in eliminating those residents. I regularly run the viewer on an older model Pentium 4. Sheet Spotter ___ 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
[opensource-dev] Building viewer-development
I would like to build the viewer-development source code under Windoze. I was familiar with the Snowglobe process. Now I need to understand any changes to the build process for Project Snowstorm. The wiki instructions for the retrieving the source code and building the viewer seem out of date. http://wiki.secondlife.com/wiki/Get_source_and_compile http://wiki.secondlife.com/wiki/Microsoft_Windows_Builds Should these pages be marked out of date and include links to the newer Project Snowstorm pages? Only the version control repository page was marked as out of date. http://wiki.secondlife.com/wiki/Version_control_repository The Project Snowstorm page links to a page that includes a discussion about retrieving the source code from the repository: http://wiki.secondlife.com/wiki/Develop_Viewer_Code I encountered two problems on the "Develop Viewer Code" page. Firstly, it took a wee while to find a client application that could retrieve the source code from the repository. Would adding links to client applications be helpful? I assume the following application is reliable: http://tortoisehg.bitbucket.org/ Secondly, there was a link to a "build" page that was expected to hold the build instructions. http://wiki.secondlife.com/wiki/How_To_Build_The_Viewer The above page was empty. Does the viewer-development build follow the same process outlined in the original "Microsoft Windows Builds" page? Are all of the third-party applications (CMake, Cygwin, Python, etc) still required? Are Artwork and Libraries bundles from the following page still required? http://wiki.secondlife.com/wiki/Source_downloads Thank you in advance for help in getting a viewer-development build happening under Windoze. Sheet Spotter ___ 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
Re: [opensource-dev] J2C fast decoder
Some comments on SNOW-361 (Upgrade to OpenJPEG v2) suggested that changing to version 2 of OpenJPEG might improve performance, while other comments suggested it might not support progressive decoding. http://jira.secondlife.com/browse/SNOW-361 Is an upgrade to OpenJPEG v2 under active development? Sheet Spotter _ From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Philippe (Merov) Bossut Sent: September 9, 2010 10:35 PM To: Nicky Fullton Cc: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] J2C fast decoder Hi Nicky, As it happens, I've been working on instrumenting the code to add metric gathering for image decompression as part of the Snowstorm sprint. You may want to use my branch (https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and create a baseline for openjpeg then run a test for Jasper. You'll have to sort out the failing cases certainly and just throw them so we compare what gets truly decompressed (though, clearly, working in all cases is pretty critical if we look at Jasper as an alternative). Here's what I got comparing KDU and OpenJpeg: Label Metric KDU(B) OJ2C(T) Diff(T-B) Percentage(100*T/B) ImageCompressionTester-1 TotalBytesInDecompression50486435003370-4527399.1 TotalBytesOutDecompression 40415336 465928966177560115.29 TimeTimeDecompression3.74 17.04 13.3 455.39 ImageCompressionTester-2 TotalBytesInDecompression50007445000144 -600 99.99 TotalBytesOutDecompression 46440040 44248324 -219171695.28 TimeTimeDecompression3.64 15.02 11.37 412.02 For that test, I output data every time 5MB of compressed data have been processed. It's partial but shows that OpenJpeg is roughly 4 times slower than KDU (at least, the version we're using in the official viewer currently). Would be nice to have a similar set of numbers for Jasper before going too far down the implementation path. I wrote a short (and still incompleted) wiki to explain a bit how the metric gathering system works: - https://wiki.secondlife.com/wiki/Performance_Testers BTW, that's something we should be using more generally for other perf sensitive areas, especially when starting a perf improvement project. See http://jira.secondlife.com/browse/VWR-22761 for details. Cheers, - Merov On Fri, Sep 3, 2010 at 9:05 AM, Nicky Fullton wrote: Hello, >> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000 >> images, after a short test with openjpeg2000 from EPFL we have tested >> last 3 days JasPer (only a POC apps to do some bench), we must do a lot >> of work too, but this is a lil question... anybody here around never >> tried it as alternative to OpenJPEG/KDU in a viewer? >I'm not aware of anyone publishing results for such a test, but if you >have the time it would be interesting reading. You might be interested in: http://bitbucket.org/NickyD/viewer-development/changeset/027bf44c5582 I made a rather quick hack to try Jasper instead of OpenJpeg to decode images. The patch has some very rough edges. In fact is the decoding into the LLImageRaw buffer not correct. I did not fix this (yet) because the results so far are not very promising. Jasper can only decode around 20% of the jpeg, for the other 80% it will create an error and then my code falls back to OpenJpeg. This fallback makes the whole decoding rather slow, so it is hard to say if Jasper would really be any faster. Right now I am not sure if it would be reasonable to invest more time looking at Jasper. First the code would need to fixed upstream, so all images can be properly decoded. As this project looks rather dead, one with JPEG2000 knowledge might have to step up for this. On another note, you might like to try: http://bitbucket.org/NickyD/viewer-development/changeset/e4eff3e2af39 This will at least skip the step of calling OpenJpeg in LImageJ2COJ::getMetadata (if possible, it will do sanity checks first). >Some things to keep in >mind. OpenJpeg has patches floating around on its ML against 1.3 that >reports have claimed up to 40% speed increase in places due to >unrolling the inner loops so finding them and testing would be good. I did not find any of those, but then again maybe I did not look hard enough. There is certainly some potential in OpenJpeg. There are some loops in t1_dec_sigpass and t1_dec_refpass that can be easily rewritten. But there is some pretty tricky stuff in t1_dec_clnpass that would need some cleaning and mqc decoder (mqc_decode) burns a lot of time. But that one is especially hairy as it has side effects on its input parameter. I am not sure if anyone without enough deep knowledge of
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
I would love to see Robin's test harness. I would also love to see the images that failed with v2. I started diving into the v2 branch of OpenJPEG a few days ago, after research JPEG 2000 for a week. Tackling the bugs from the failed images might be a good way to become more familiar with the source code. I posted a very minor patch correcting some simple build problems with the DLL version of OpenJPEG V2. http://code.google.com/p/openjpeg/issues/detail?id=40 Does anyone have a sense of how actively the OpenJPEG source code is maintained? Thank you for publishing your results, Robin. They are encouraging me to continue looking at OpenJPEG v2. Sheet Spotter -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Lillian Yiyuan Sent: September 21, 2010 4:24 PM Cc: opensource-dev Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics Could you publish the test harness, I would like to try this on the mac with a mactools build of v2 On Tue, Sep 21, 2010 at 2:49 PM, Robin Cornelius wrote: > On Tue, Sep 21, 2010 at 7:44 PM, Aidan Thornton wrote: >> On 9/21/10, Robin Cornelius wrote: >>> I'm still not 100% sure why the build of openjpeg supplied by imprudence >>> is better than my builds on 2005. >> >> Imprudence is using the openjpeg SVN trunk version from a few months >> ago, which is essentially a pre-release version of openjpeg 1.4 and is >> slightly more optimised than 1.3. > > I built off revision 635 from trunk and tried with no SSE/SSE1 and > SSE2 as per my results, SSE1 on 2008 gives the best effect, SSE2 is a > disaster all around on my setup. > > Robin > ___ > 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
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
There may be another option for obtaining a common set of J2C files for comparison. Viewer 2 installs 784 JPEG-2000 files (*.j2c) in the "local_assets" folder under the main install folder (e.g., "C:\Program Files\SecondLifeViewer2"). The "j2k_metric" test harness decoded all 784 files from the "local_assets" folder without errors. The OpenJPEG 1.3.0 library was 3.7 times slower than the KDU library that comes with Viewer 2.1.1.208043 (the current release version). I have been unsuccessful at implementing the additional functions to make the OpenJPEG v2 interface compatible with the earlier v1.3.0 interface. The test application aborted with buffer overrun errors. Oopsie! The tests were run under Windoze 7 on a Pentium i7-950 (3 GHz Hyperthreaded) using a RelWithDebInfo build run from the command line. (Running the same build from within VisualStudio 2005 was noticeably slower. There was one small surprise. Only two threads were in use for both the OpenJPEG v1.3.0 and KDU tests. I expected KDU to use all eight available threads. Sheet Spotter -Original Message- From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Robin Cornelius Sent: September 22, 2010 2:00 PM To: Arrehn Oberlander Cc: opensource-dev Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics On Wed, Sep 22, 2010 at 7:35 PM, Arrehn Oberlander wrote: > Is it possible for you to release your test harness for these comparisons, > including the texture set? I can't give out the texture set, hopefully as per a previous discussion on this topic, we can assemble a good texture set that we can all share and compare metrics. the code can be found at http://bitbucket.org/robincornelius/viewer-development-j2c-metrics The code although based on 2.X should still work on 1.X (my original tests were a 1.X build) but i wanted to clean this up a bit before release and to be honest we are concerned with openjpeg/kdu not the viewer for these tests, my test code itsself is painfully simple. Load a texture into an LLImage, run decode time it. repeat and rince. The code forms a seperate project "j2k_metric" which depends on llcommon/llimage/llimagej2coj and llvfs (cmake rules included to make it build out of the box. But to make it run you need to set the working directory to be the sharedlibs folder (or copy dlls/so's around) as i've not bothered to stage it yet (patches welcome) The exe accepts one command line argument and that is the path to a folder of textures, if no path is given it assumes a default path of "C:\Textures" to make things a tiny bit easier on windows. Hope this is enough to get people started Robin ___ 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
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
I created a crude profiling tool to determine where to focus on improving the performance of OpenJPEG v2. The profiling tool records the number of function calls and combined execution time for every function in the main source files (openjpeg.c, j2k.c, dwt.c, tcd.c, t1.c, mqc.c, and raw.c). Results from running the test harness on the 748 files from the "local_assets" folder were recorded in a CSV (Comma-Separated Value) format. The results were placed here: http://pastebin.com/7K9PCFcB The three columns in the file are: 1. Function name 2. Number of times the function was called 3. Combined execution time for the function. The order the rows appear in the file is not significant. (You can sort the rows in any order you like after importing the file into a spreadsheet.) Enabling the profiling tool definitely distorts the results. Overall execution time for the test increased from 21 seconds to 129 seconds. The crude profiling tool was able to identify where most of the decoding time is spent. Only a small number of routines are responsible for most of the execution time. Hopefully this information can lead to improvements in the performance of the OpenJPEG v2 library. Sheet Spotter -Original Message- From: Robin Cornelius [mailto:robin.cornel...@gmail.com] Sent: September 23, 2010 5:37 AM To: Sheet Spotter Cc: opensource-dev Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics On Thu, Sep 23, 2010 at 3:40 AM, Sheet Spotter wrote: > There may be another option for obtaining a common set of J2C files for > comparison. > > Viewer 2 installs 784 JPEG-2000 files (*.j2c) in the "local_assets" folder > under the main install folder (e.g., "C:\Program Files\SecondLifeViewer2"). > > The "j2k_metric" test harness decoded all 784 files from the "local_assets" > folder without errors. The OpenJPEG 1.3.0 library was 3.7 times slower than > the KDU library that comes with Viewer 2.1.1.208043 (the current release > version). Hi (again) Sheet and everyone else, I've started another sheet with a fresh set of results on another system of mine, please feel free to add your own tests rows https://spreadsheets.google.com/ccc?key=0AiSrUP47_VxIdEZ4NmlSY281UXFac0ZZTkV jWGJtV1E&hl=en&authkey=CIGY9M4O If you want to compare to KDU you need to compare to KDU on your system don't compare to by KDU results or anyone elses, thats not a fair comparision. OJP 2.0 is not playing nice with the local_asset texture set needs some work. Robin ___ 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
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
Execution time from the profile includes sub-functions. For example, the tcd_t1_decode function calls the t1_decode_cblks function multiple times. The execution time for tcd_t1_decode includes the time for every call to t1_decode_cblks. The t1_decode_cblk function was responsible for most of the execution time (121 out of 128 seconds). Almost all of this time in this function is split between three other functions t1_dec_sigpass (51 seconds), t1_dec_refpass (36 seconds), and t1_dec_cInpass (35 seconds). Each of these functions make millions of calls to only a few other functions. The profiler was written very simply. The profiler consists of a single CProfiler class in C++. The constructor records the start time using a high resolution timer. The destructor calculates the elapsed time and updates a collection of counters. Declaring a variable of the CProfiler class is all that's required to capture the execution time and call count. The constructor accepts a single argument, which is used as a unique identifier. Results are grouped by this identifier. The name of the function was used at the unique identifier. After running the simulation a static method is called to dump the statistics. The most expensive part of the coding was adding CProfiler variables to the start of each function. No attempt was made to subtract out the time spent in sub-routines. No attempt was made to subtract out the impact of the CProfiler class itself. The CProfiler class will not be submitted to the OpenJPEG source code. Comments in their Google group suggest they prefer to limit the source code to C and are not interested in using C++ objects. Sheet Spotter _ From: lee.sai...@gmail.com [mailto:lee.sai...@gmail.com] On Behalf Of Ponzu Sent: September 26, 2010 10:03 AM To: Sheet Spotter Cc: Robin Cornelius; opensource-dev Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics Does the execution time *include* the time of sub-functions called, or does it *exclude*? On Sun, Sep 26, 2010 at 3:02 AM, Sheet Spotter wrote: I created a crude profiling tool to determine where to focus on improving the performance of OpenJPEG v2. ___ 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
Re: [opensource-dev] Openjpeg/KDU the cold hard metrics
I found a simple fix to the OpenJPEG v2 library that corrects the previous crashes that occurred with the test harness. The fix is attached to https://jira.secondlife.com/browse/SNOW-361 I also updated Robin's spreadsheet to reflect the improved performance. OpenJPEG v2 is now marginally quicker than the OpenJPEG v1.3.0 that ships with Viewer 2. Previously the OpenJPEG v2 library was crashing when it skipped over packets for higher discard levels. The library was skipping over too few bytes. Earlier test results for OpenJPEG v2 were performing a full decode. The "Reduce" feature (that performs partial decodes when the image was incomplete) had to be disabled because of the crashes. Now that the crashes are fixed, the updated test results for v2 reflect the same partial decodes that OpenJPEG v1.3.0 was performing. The fix will likely be submitted to the OpenJPEG project tomorrow night, when I have more time. Sheet Spotter -Original Message- From: Robin Cornelius [mailto:robin.cornel...@gmail.com] Sent: September 23, 2010 5:37 AM To: Sheet Spotter Cc: opensource-dev Subject: Re: [opensource-dev] Openjpeg/KDU the cold hard metrics On Thu, Sep 23, 2010 at 3:40 AM, Sheet Spotter wrote: > There may be another option for obtaining a common set of J2C files for > comparison. > > Viewer 2 installs 784 JPEG-2000 files (*.j2c) in the "local_assets" folder > under the main install folder (e.g., "C:\Program Files\SecondLifeViewer2"). > > The "j2k_metric" test harness decoded all 784 files from the "local_assets" > folder without errors. The OpenJPEG 1.3.0 library was 3.7 times slower than > the KDU library that comes with Viewer 2.1.1.208043 (the current release > version). Hi (again) Sheet and everyone else, I've started another sheet with a fresh set of results on another system of mine, please feel free to add your own tests rows https://spreadsheets.google.com/ccc?key=0AiSrUP47_VxIdEZ4NmlSY281UXFac0ZZTkV jWGJtV1E&hl=en&authkey=CIGY9M4O If you want to compare to KDU you need to compare to KDU on your system don't compare to by KDU results or anyone elses, thats not a fair comparision. OJP 2.0 is not playing nice with the local_asset texture set needs some work. Robin ___ 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
[opensource-dev] Overview of JPEG 2000 codec
Anyone interested in looking at the OpenJPEG source code will find this overview helpful. http://j2000.almacom.com/j2ksrc/docs/overview.html The overview describes the main components of the original source code on which the OpenJPEG source code is based. The OpenJPEG source code is newer and likely more efficient than the original source code, but the overview is still quite accurate. The original source code is also available from the same web site. The main page states "The source code for the codec is freely available for anyone to study or even for use in commercial programs". Sheet Spotter ___ 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
[opensource-dev] Infinite loop in viewer-development?
A stack overflow is occurring during log on with the latest viewer-development source code. The code enters an infinite loop when two methods are repeatedly calling each other. LLVOAvatarSelf::removeMissingBakedTextures calls LLVOAvatar::updateMeshTextures, which in turn calls LLVOAvatarSelf::removeMissingBakedTextures. Clearing cache has no effect. The infinite loop still occurs on the next logon. Is anyone aware of the underlying cause of the infinite loop? Is there a workaround that would avoid this infinite loop? The problem may not be new. The same infinite loop occurs with source code that I checked out six weeks ago. Sheet Spotter ___ 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
Re: [opensource-dev] Infinite loop in viewer-development?
The infinite loop occurs when the avatar's baked textures cannot be decoded. The problem was encountered while testing OpenJPEG v2, but it could also occur with any JPEG 2000 decoder. After running the code outside the debugger I was able to submit a rather large crash log (13 MB). I would like to create a JIRA entry with more details. Does the new JIRA entry belong under the Snowstorm or VWR project? I would happily add a description of the source code revision number to the JIRA entry. Is the following an adequate description of this revision? Changeset 13413 (1a5850ad0a74) Including a revision number with my original questions did not seem important, since the problem appeared to be present for six weeks or more. I also did not include any hardware or operating system information because the problem was occurring in source code that is common to all platforms. I tried to keep the description brief and to the point. Sheet Spotter _ From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Oz Linden (Scott Lawrence) Sent: November 10, 2010 10:39 AM To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Infinite loop in viewer-development? A stack overflow is occurring during log on with the latest viewer-development source code. See the archive for my rant on using the word "latest". The code enters an infinite loop when two methods are repeatedly calling each other. LLVOAvatarSelf::removeMissingBakedTextures calls LLVOAvatar::updateMeshTextures, which in turn calls LLVOAvatarSelf::removeMissingBakedTextures. Clearing cache has no effect. The infinite loop still occurs on the next logon. Is anyone aware of the underlying cause of the infinite loop? Is there a workaround that would avoid this infinite loop? The problem may not be new. The same infinite loop occurs with source code that I checked out six weeks ago. This certainly is not happening for everyone... if you can figure out what condition is triggering it for you, that would be good information to have. ___ 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
[opensource-dev] OpenJPEG v2 progress update
I have been quietly working on improving the performance of OpenJPEG v2 for a number of weeks. The focus was on testing an enhancement to one of the internal decoder algorithms. Results with the OpenJPEG test applications showed a 25% improvement in the decoder performance. More recent results have cast doubt on those improvements. The test harness created by Robin Cornelius loads a list of J2C images using a test stub built within the viewer framework. Some images decoded more than 75% faster, while others were 500% slower. The investigation of those results is ongoing. In the last few days I learned that the current viewer patches for OpenJPEG v2 (i.e., http://jira.secondlife.com/browse/SNOW-361 ) do not produce a usable viewer. Decoding a truncated image will report a warning of "Stream has reached its end" or "Stream too short". Almost the entire scene is rendered in gray. My focus is now shifting from working on a faster OpenJPEG v2 to ensuring that OpenJPEG v2 will produce a usable viewer. I am interesting in hearing from anyone else (publicly or privately) that has made progress in creating a usable viewer with OpenJPEG v2. Sheet Spotter ___ 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
