[sldev] projects list
Mike Monkowski
monkowsk at watson.ibm.com
Thu Dec 18 11:45:42 PST 2008
Glen wrote:
> Just examples. I am interested in threading it, but that's a bigger job
> than someone unfamiliar with code base can dream of taking on. Dual (or
> quad) CPUs aren't much of a boon without actually using any concurrency.
The viewer does use some helper threads. The rendering itself is
confined to a single thread because OpenGL is difficult (if at all
possible) to run multithreaded.
> Essentially, I'm most interested in finding ways of squeezing
> performance out of it to match what the video card can actually do. I
> know it can be faster than 6fps on a 256MB ATI HD2600 with all
> enhancements turned off!
You can get an idea of which parts of the viewer are consuming the
resources by running the Fast Timers (Advanced->Consoles->Fast Timers).
That will let you decide where your efforts would be best applied.
> I'm also interested in reducing / eliminating the dependence on licensed
> technology in the viewer, so if someone grabs the code they don't need
> to worry about something not working because a proprietary bit wasn't
> included in the source release. FMod / Vivox are two examples.
Linden is already pretty far along replacing Fmod with OpenAL thanks to
some open source work http://jira.secondlife.com/browse/VWR-2662
Replacing Vivox is tough because Vivox hosts the voice servers. Of
course, you could replace that as well. The good news, though, is that
Vivox intends to open source some of their code, probably in 2009.
> Those are where I'd like to go, but as far as I'd get with any of it is
> really very much up in the air. I always have 50+ projects in the works.
> That's kind of why I was thinking of finding a clearing-house for
> people's ongoing viewer projects, so that if I found myself with the
> extra time to help out with something then I could pick & choose where I
> could do the most good.
There are a few established alternate viewer groups (see
http://wiki.secondlife.com/wiki/Alternate_viewers ). That would
probably be your best bet for collaborative work.
Mike
More information about the SLDev
mailing list