Re: [opensource-dev] 1.4 Showstopper: Reopened: VWR-9475

[Henri Beauchamp]

On Tue, 3 Aug 2010 01:24:48 +0200, Aleric Inglewood wrote:

> Hi Brian,
> 
> doc/asset_urls.txt contains the line
> 
> SLASSET_ART=
> http://automated-builds-secondlife-com.s3.amazonaws.com/oss-viewer/export/slviewer-artwork-oss-viewer-1.23.4.0.zip
> 
> Downloading that and checking it with unzip -l shows that there is no
> res-sdl in it.
> 
> Is that url not correct? Or did you expect this zip file to contain the
> cursor bit maps?

The cursors (*.cur files) are in there, in the res/ directory...

But the bitmaps are part of the SDL pre-built library, which means that
when doing a standalone build (that doesn't fetch the pre-built libararies),
you don't get the bitmaps installed... Not sure why the bitmaps have been
moved to the pre-built SDL library package, but it's definitely a wrong move !

Henri.
___
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] Missing artwork and library files.

[Henri Beauchamp]

On Wed, 7 Jul 2010 16:57:47 +0200, Aleric Inglewood wrote:

> I'm trying to update the wiki on how to build the viewer (on linux).
> I noted that it requires you to download files that don't exist.
> This was reported before on SNOW-604 but still not restored by Linden Lab.
> 
> The only right way would be if Linden Lab adds them back, but...

Any news on this ?

The files for v1.13.5 are still missing while I gave to Merov the
pointers to at least the Linux tarballs about one month ago at
an Hippo meeting...

Here there are again:

http://sldev.free.fr/sources/slviewer-artwork-viewer-rc-frozen-1.23.5.136274.zip
http://sldev.free.fr/sources/slviewer-linux-libs-viewer-rc-frozen-1.23.5.136274.tar.gz
http://sldev.free.fr/sources/slviewer-src-viewer-rc-frozen-1.23.5.136274.tar.gz

Henri.
___
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] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Hi,

I believe I found another solution.

In my research as I optimized graphics routines in the viewer, I 
achieved between 100% to 150% increase in rendering performance. To be 
fair, I reported as "up to 100%".

There overall frame loop has many tasks, so keep that in mind that 
overall performance increase noted are of tasks that directly related to 
rendering itself.

I was blackboxed from the results when deployed. I admit, it pissed me 
off how that was done, even if I had a right to be pissed, ... meh.

However, I found out that "shown" results were actually not even my 
fault. I even realize they aren't of the of fault of those who 
immediately  worked around with me on it. Of what little I had to work 
with, it didn't make sense, and the obvious thing was to "fix" it as a bug.

I think some of us realize it was no software bug. I can understand 
while the market plays to GPUs, that such any performance increase that 
would generally help everybody would be held back because of  
"overclockers".

I don't think it matters anymore, and no need to keep something that 
isn't a secret as a secret anymore.

Let's just say that I was visualizing how the "streaming media 
extensions" work through the hardware. Then I realized that the obvious 
answer was that "overclockers" were reporting problems yet they weren't 
telling they overclocked. The visualization I had led me to decide that 
is the logical explanation.

"Overclocking"... don't do that!  We have proven that the overall 
performance in rendering "sucks" for the larger general audience due to 
the "few" that report "knowledge" of their "crashes" from "overclocking" 
yet  those details aren't even being recorded even when fully not 
blackboxed.

Even where there is no crashes...  it is only a demostrations of where 
the GPU actuall fails... and not the CPU...  of course there is no 
crash. The GPU is preventing itself... it only overheats... hides itself 
and "BURN".

Enjoy!


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Was just thinking of a secondary proof to this. This should be helpful 
to traditional physicist: Dark Liquid Crystal.

The significant thing to note is how light "slows" or "refracts" as 
noted by dark matter... when taken to a substate.

On that note... it's not for me to "doctor" the Rx, and I know someone 
that wants...



heh... "BURN"...  love it!

Oh let's "share" this one... LMAO



P.S. Working On It 2.0...



Dzonatas Sol wrote:
> Hi,
>
> I believe I found another solution.
>
> In my research as I optimized graphics routines in the viewer, I 
> achieved between 100% to 150% increase in rendering performance. To be 
> fair, I reported as "up to 100%".
>
> There overall frame loop has many tasks, so keep that in mind that 
> overall performance increase noted are of tasks that directly related 
> to rendering itself.
>
> I was blackboxed from the results when deployed. I admit, it pissed me 
> off how that was done, even if I had a right to be pissed, ... meh.
>
> However, I found out that "shown" results were actually not even my 
> fault. I even realize they aren't of the of fault of those who 
> immediately  worked around with me on it. Of what little I had to work 
> with, it didn't make sense, and the obvious thing was to "fix" it as a 
> bug.
>
> I think some of us realize it was no software bug. I can understand 
> while the market plays to GPUs, that such any performance increase 
> that would generally help everybody would be held back because of  
> "overclockers".
>
> I don't think it matters anymore, and no need to keep something that 
> isn't a secret as a secret anymore.
>
> Let's just say that I was visualizing how the "streaming media 
> extensions" work through the hardware. Then I realized that the 
> obvious answer was that "overclockers" were reporting problems yet 
> they weren't telling they overclocked. The visualization I had led me 
> to decide that is the logical explanation.
>
> "Overclocking"... don't do that!  We have proven that the overall 
> performance in rendering "sucks" for the larger general audience due 
> to the "few" that report "knowledge" of their "crashes" from 
> "overclocking" yet  those details aren't even being recorded even 
> when fully not blackboxed.
>
> Even where there is no crashes...  it is only a demostrations of where 
> the GPU actuall fails... and not the CPU...  of course there is no 
> crash. The GPU is preventing itself... it only overheats... hides 
> itself and "BURN".
>
> Enjoy!
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
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] The avatar name on the login screen in Viewer 2.

[Marine Kelley]

Hi Suezanne, you may want to look at the method LLPanelLogin::setFields() in
newview/llpanellogin.cpp

Marine

On 3 August 2010 06:31, SuezanneC Baskerville  wrote:

> Where is the remembered username stored, where is read and written in the
> source code, and how do you make it not appear on your login screen?
>
> By "remembered username"  I mean the username that appears pre-filled on
> the login screen in Viewer 2.
>
> Someone asked  in the forums how you make the username be blank when you
> launch Viewer 2.  That drove me to looking at the source code to find where
> the name is fetched from and I haven't been able to find it so far.
>
> I'm asking here because I don't know any better place to find people that
> are familiar with SL source code.
>
> Thanks,
>
> Sue Baskerville
>
>
>
>
> ___
> 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] Open Source meeting 08-03

[Oz Linden (Scott Lawrence)]

Merov is on vacation this week and next, and I am unfortunately tied up 
this afternoon so neither of us will be available to host the 
Hippotropolis meeting today.   By all means feel free to hold it without us.


___
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] Performance: 100%-150% increase in rendering

[Dzonatas Sol]

Hi,

I understand your leading question.

It leads me to the conclusion that we should allow public Second Life 
Groups to automatically allow or disallow features within the client 
viewer architecture.

That probably doesn't make sense unless you read the source, yet there 
are so many people that don't read the source.

I started to think about a "Doctor" group, as in Science-of-the-Arts 
Doctor. I think universities may need such funding^B^B^B^B, especially 
if they own the group as a piece of content they create. It's not 
obvious, yet between Second Life land and a Second Life group the 
features already exist to create a certain desired flow.

It's like... i have a set of minimal features needed...  here is a 
larger set that provides them. It doesn't make sense to you unless you 
understand the minimal features needed.

Chat in those groups are optional, yet I think SL may want to consider 
group-chat-rates for real institutions and commercial businesses that 
reach a certain threshold.

Note that the significant feature here is the group acts as "flags" 
internally and externally to the source code... if you strip out what 
you know about chat and some other features. Start with that idea and 
catch-up... because we didn't have to change it.


Nexii Malthus wrote:
> ..What?
>
> - Nexii
>
> On Tue, Aug 3, 2010 at 4:44 PM, Dzonatas Sol  > wrote:
>
> Was just thinking of a secondary proof to this. This should be helpful
> to traditional physicist: Dark Liquid Crystal.
>
> The significant thing to note is how light "slows" or "refracts" as
> noted by dark matter... when taken to a substate.
>
> On that note... it's not for me to "doctor" the Rx, and I know someone
> that wants...
>
>
>
> heh... "BURN"... �love it!
>
> Oh let's "share" this one... LMAO
>
>
>
> P.S. Working On It 2.0...
>
>
>
> Dzonatas Sol wrote:
> > Hi,
> >
> > I believe I found another solution.
> >
> > In my research as I optimized graphics routines in the viewer, I
> > achieved between 100% to 150% increase in rendering performance.
> To be
> > fair, I reported as "up to 100%".
> >
> > There overall frame loop has many tasks, so keep that in mind that
> > overall performance increase noted are of tasks that directly
> related
> > to rendering itself.
> >
> > I was blackboxed from the results when deployed. I admit, it
> pissed me
> > off how that was done, even if I had a right to be pissed, ... meh.
> >
> > However, I found out that "shown" results were actually not even my
> > fault. I even realize they aren't of the of fault of those who
> > immediately �worked around with me on it. Of what little I had
> to work
> > with, it didn't make sense, and the obvious thing was to "fix"
> it as a
> > bug.
> >
> > I think some of us realize it was no software bug. I can understand
> > while the market plays to GPUs, that such any performance increase
> > that would generally help everybody would be held back because
> of
> > "overclockers".
> >
> > I don't think it matters anymore, and no need to keep something that
> > isn't a secret as a secret anymore.
> >
> > Let's just say that I was visualizing how the "streaming media
> > extensions" work through the hardware. Then I realized that the
> > obvious answer was that "overclockers" were reporting problems yet
> > they weren't telling they overclocked. The visualization I had
> led me
> > to decide that is the logical explanation.
> >
> > "Overclocking"... don't do that! �We have proven that the overall
> > performance in rendering "sucks" for the larger general audience due
> > to the "few" that report "knowledge" of their "crashes" from
> > "overclocking" yet �those details aren't even being recorded
> even
> > when fully not blackboxed.
> >
> > Even where there is no crashes... �it is only a demostrations of
> where
> > the GPU actuall fails... and not the CPU... �of course there is no
> > crash. The GPU is preventing itself... it only overheats... hides
> > itself and "BURN".
> >
> > Enjoy!
> >
> >
>
>
> --
> --- https://twitter.com/Dzonatas_Sol ---
> Web Development, Software Engineering, Virtual Reality, Consultant
>
> ___
> 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
>
>


-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies befo