[opensource-dev] Reminder: No Daily Scrum tomorrow (9/14) - Instead, Sprint Planning from 7-9am PT

Hi all, Just a quick reminder that we won't meet tomorrow at 6:30am PT for the Daily Scrum. Instead we'll meet from 7-9am PT for Sprint 4 Planning. With the big Jira switchover, I'm a bit behind organizing stories and defects for this sprint, but will try to get us ready tonight! See you tomorro

Re: [opensource-dev] J2C fast decoder

Hi, Very interesting discussion though it seems that folks collide several things when talking about "textures" in general terms: there's a load of difference between a repetitive 64x64 texture used to tile a brick wall and a photographic quality 1024x1024 texture. The former could certainly benef

Re: [opensource-dev] where is the source

On 9/13/2010 19:56, Yoz Grahame wrote: > > On 13 September 2010 16:48, Joshua Bell > wrote: > > > The server side changes to deliver a static URL to an LLSD > resource from login are minimal; if someone wants to take a stab > at the client side changes and

Re: [opensource-dev] where is the source

On 13 September 2010 16:48, Joshua Bell wrote: > > The server side changes to deliver a static URL to an LLSD resource from > login are minimal; if someone wants to take a stab at the client side > changes and defining a forward-looking LLSD format, I'm sure you'll find a > server-side champion.

Re: [opensource-dev] where is the source

Is this JIRA related VWR-20031 Automatic download of syntax-table ?? Perhaps add your comments and votes : ) On 14 September 2010 00:48, Joshua Bell wrote: > On Mon, Sep 13, 2010 at 4:32 PM, Kelly Linden

Re: [opensource-dev] where is the source

On Mon, Sep 13, 2010 at 4:32 PM, Kelly Linden wrote: > I'd love to see that syntax highlighting and hover tip code replaced, we > really shouldn't need anything in lscript in the viewer. If the syntax > highlighting / hover tips could be read from an LLSD we could provide a > capability 'lsl-synt

Re: [opensource-dev] where is the source

As I recall, all that lscript stuff was to compile the LSL bytecode and give it to the server. It shouldn't be needed anymore since the server compiles everything itself... Rob On 9/13/2010 4:32 PM, Kelly Linden wrote: I'd love to see that syntax highlighting and hover tip code replaced, we

Re: [opensource-dev] where is the source

I'd love to see that syntax highlighting and hover tip code replaced, we really shouldn't need anything in lscript in the viewer. If the syntax highlighting / hover tips could be read from an LLSD we could provide a capability 'lsl-syntax' which could be queried for a version or the whole map. Then

[opensource-dev] Snowstorm Daily Scrum Summary - 09/13/2010

Date: Mon Sep 13, 2010 Also available here: https://wiki.secondlife.com/wiki/Snowstorm_Daily_Scrum_Archive *=== General Notes ===* * Last day of Sprint 3! * Merge Monkey of the Day: Merov *===Team Status===* * * * Aimee Linden PAST * STORM-121 Clean-up of voice client shutdown FUTURE *

Re: [opensource-dev] where is the source

I believe that that code is used for the syntax highlighting - and indeed, " llGetLinkPrimitiveParams()" doesn't highlight in the viewer... -- cg On Mon, Sep 13, 2010 at 11:44 AM, Altair Sythos wrote: > On Mon, 13 Sep 2010 16:47:28 +0200 > "Garmin Kawaguichi" wrote: > > > Is it the last last s

Re: [opensource-dev] Retaining Newbies (Was: The Plan for Snowglobe)

dilly dobbs wrote: > Now we need to get others to come and chat about it and see if we can > come up with a plan. Have a look at VWR-10293 and don't skip all of the closed issues there. Many were closed because of Linden's perception that they had fixed the new user experience when they got

Re: [opensource-dev] where is the source

On Mon, 13 Sep 2010 16:47:28 +0200 "Garmin Kawaguichi" wrote: > Is it the last last source code? > > I say that after reading : > https://bitbucket.org/lindenlab/viewer-development/src/tip/indra/lscript/lscript_library/lscript_library.cpp > where llClearPrimMedia is the last function. Where are

Re: [opensource-dev] where is the source

LSL-related code in the viewer tree is mostly vestigial at this point - the server code has its own private tree which diverged over a year ago. Garmin Kawaguichi wrote: > Is it the last last source code? > > I say that after reading : > https://bitbucket.org/lindenlab/viewer-development/src/tip

Re: [opensource-dev] This cannot be right...

Check out http://jira.secondlife.com/browse/VWR-22757 and http://jira.secondlife.com/browse/VWR-18427 I don't know why 209046 would be worse than prior releases, but it would be nice to know that OSX builds do or don't have the same issue. On 09/09/2010 01:07 PM, Ponzu wrote: When I start

Re: [opensource-dev] where is the source

Is it the last last source code? I say that after reading : https://bitbucket.org/lindenlab/viewer-development/src/tip/indra/lscript/lscript_library/lscript_library.cpp where llClearPrimMedia is the last function. Where are : llSetLinkPrimitiveParamsFast, llGetLinkPrimitiveParams, llLinkParticle

Re: [opensource-dev] Retaining Newbies (Was: The Plan for Snowglobe)

On Mon, Sep 13, 2010 at 3:22 PM, dilly dobbs wrote: > Thanks OZ > Now we need to get others to come and chat about it  and see if we can come > up with a plan. The best way is to just put out a general call for a meeting with a set a date and a time. Or possibly 2 to try to accommodate different

Re: [opensource-dev] Retaining Newbies (Was: The Plan for Snowglobe)

Thanks OZ Now we need to get others to come and chat about it and see if we can come up with a plan. I love deadlines. I like the whooshing sound they make as they fly by Douglas Adams On Mon, Sep 13, 2010 at 9:17 AM, Oz Linden (Scott Lawrence) < o...@lindenlab.com> wrote: > On 2010-09-11

Re: [opensource-dev] Retaining Newbies (Was: The Plan for Snowglobe)

On 2010-09-11 14:11, Dilly Dobbs wrote: On 9/11/2010 1:05 PM, Robert Martin wrote: On Sat, Sep 11, 2010 at 1:52 PM, dilly dobbs wrote: We all seem like intelligent adults that could come to an agreement on how to add priority to the issues that we would like to see addressed. And yes i w

Re: [opensource-dev] J2C fast decoder

It goes even further. JPEG2k is superior in compression ratio compared to quality to both, JPEG and PNG when it comes to lossy and lossless. it is actually a quite awesome image format through and through. The only real problem with JPEG2k are software patents. It's the reason why free decoders li

Re: [opensource-dev] J2C fast decoder

Notice that old JPG does not support alpha channels (transparency). That means abandoning JPEG2000 would in fact force everyone with a single transparent pixel (even if just corners of round textures) to use lossless PNG for that, which is not optimal, to say the least. Inté, Leonel -Origin

Re: [opensource-dev] J2C fast decoder

On 2010-09-13, at 00:40, Tateru Nino wrote: > If we're using HTTP textures, is there actually any need for the JPEG 2000 > format? Since the transfer time of individual textures is vastly reduced > (from the first byte to the last byte) the intermediate quality levels > supported by jpg2k would

Re: [opensource-dev] Client side scripting.

The hard part isn't coming up with an embedded scripting language, it's not even coming up with a secure set of bindings that don't allow for unanticipated side-effects or privilege escalation, it's integrating the scripting engine into an event loop that wasn't designed to have a scripting engi

Re: [opensource-dev] J2C fast decoder

> Would it be a huge problem, for example, to transfer HTTP textures > as TGA or PNG and use one of the rather well-optimized decoder TGA have lossless RLE compression anyway transport is format-indipendent, you can send on HTTP voice too (like skype) or anything you want. To increase bandwith

Re: [opensource-dev] J2C fast decoder

On Mon, Sep 13, 2010 at 12:24 AM, Tateru Nino wrote: > Wouldn't we be making a network saving by omitting the discard levels > entirely? Granted, I don't have hard data about that - would the base > texture encoded in a lighter-weight format end up causing less data to > traverse for a given textu

Re: [opensource-dev] J2C fast decoder

Requesting a discard level means you only get a portion of the entire file, and if you wanted the highest resolution you would download the entire file which would include all discard levels. The advantage of being able to request only what you need can save a lot of network traffic. You don't real

Re: [opensource-dev] J2C fast decoder

Wouldn't we be making a network saving by omitting the discard levels entirely? Granted, I don't have hard data about that - would the base texture encoded in a lighter-weight format end up causing less data to traverse for a given texture in the long-run than the more-efficiently compressed j