Re: [opensource-dev] Review Request: VWR-25862 Fix viewer caches not being cleared.

[Aleric Inglewood]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/315/#review724
---



indra/newview/llvocache.cpp


This patch removes (everywhere, not just here) the delimiter in front of 
'mask' passed to deleteFilesInDir.

deleteFilesInDir does nothing with mask but pass it to LLDirIterator. 
Apparently, the introduction of LLDirIterator (new in Viewer 2) requires mask 
to NOT start with a delimiter.

However, you fail to correct this consistently; for example, in 
LLAppViewer::migrateCacheDirectory we have the following code:

  std::string mask = delimiter + "*.*";

  LLDirIterator iter(old_cache_dir, mask);

Can you explain that works (does it?) and the code that you changed didn't 
work?



- Aleric


On May 27, 2011, 1:04 p.m., Log Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/315/
> ---
> 
> (Updated May 27, 2011, 1:04 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a patch to fix the issues with clearing viewer caches documented in 
> VWR-25862. I removed the leading delimiter in the place where each of the 
> three caches are cleared.  I also removed the mac specific deleteFilesInDir() 
> method, which should have been removed for STORM-477. I removed unneeded 
> calls to getDirDelimiter() in llvocache.cpp.
> 
> 
> This addresses bugs vwr-25681 and vwr-25862.
> http://jira.secondlife.com/browse/vwr-25681
> http://jira.secondlife.com/browse/vwr-25862
> 
> 
> Diffs
> -
> 
>   indra/llvfs/lldir_mac.h UNKNOWN 
>   indra/llvfs/lldir_mac.cpp UNKNOWN 
>   indra/newview/llappviewer.cpp UNKNOWN 
>   indra/newview/lltexturecache.cpp UNKNOWN 
>   indra/newview/llvocache.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/315/diff
> 
> 
> Testing
> ---
> 
> Test plan: https://jira.secondlife.com/browse/VWR-25862?#comment-262800
> 
> I built and tested on Mac, Windows and Linux and saw the correct behavior 
> when clicking the clear history button and the move cache button.
> 
> 
> Thanks,
> 
> Log
> 
>

___
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] Minimum draw distance

[Jonathan Welch]

I have been working on a draw distance slider and realized this would
be a good time to have a discussion about what the lowest value you
can set your draw distance to should be.

If you have an opinion of why it should be lowered from what it is
now, 64, please reply to this message with your reasoning.

Thank you,

-Jonathan
___
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] Minimum draw distance

[holydoughnuts]

On 6/6/2011 12:37 PM, Jonathan Welch wrote:
> I have been working on a draw distance slider and realized this would
> be a good time to have a discussion about what the lowest value you
> can set your draw distance to should be.
>
> If you have an opinion of why it should be lowered from what it is
> now, 64, please reply to this message with your reasoning.
>
> Thank you,
>
> -Jonathan
When I was stuck with seriously underpowered hardware, 24m was enough to 
let me get by in the busiest places, any less than that made the camera 
act wacky. It's still possible with RenderFarClip if there is no general 
desire to let the slider drop that far, so no huge deal. Why go that 
low? Because sometimes you've got to get inworld and do stuff, even when 
it can't look good, and even that nearsighted it's a lot easier to get 
things done than in a text based client.
___
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] Minimum draw distance

[Arrehn Oberlander]

On Mon, Jun 6, 2011 at 12:37 PM, Jonathan Welch  wrote:

> ...
> If you have an opinion of why it should be lowered from what it is
> now, 64, please reply to this message with your reasoning.
>
>
I'd say it is common for me to lower draw distance to 32, for densely
populated events where the rendering of avatars alone, even with imposters,
imposes a severe rendering burden and interferes with smooth behavior of
stage effects, event effects, animations, etc.

Less common but still about 1/week, I may have to reduce draw distance to
zero briefly as a way to force texture refetches at a congested event.
Typically this happens when an annoying threshhold of avatars I'm standing
next to have seemingly permanently grey textures, because for whatever
reason, their texture fetches failed when I initially arrived, perhaps due
to poor bandwidth management/rescheduling. Despite the traffic that briefly
reducing draw distance to zero may cause, in is highly reliable at filling
on all previously grey textures that despite 10's of minutes of waiting,
will not otherwise load.
___
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] Review Request: VWR-25862 Fix viewer caches not being cleared.

[Log Linden]

> On June 6, 2011, 8:37 a.m., Aleric Inglewood wrote:
> > indra/newview/llvocache.cpp, lines 366-369
> > 
> >
> > This patch removes (everywhere, not just here) the delimiter in front 
> > of 'mask' passed to deleteFilesInDir.
> > 
> > deleteFilesInDir does nothing with mask but pass it to LLDirIterator. 
> > Apparently, the introduction of LLDirIterator (new in Viewer 2) requires 
> > mask to NOT start with a delimiter.
> > 
> > However, you fail to correct this consistently; for example, in 
> > LLAppViewer::migrateCacheDirectory we have the following code:
> > 
> >   std::string mask = delimiter + "*.*";
> > 
> >   LLDirIterator iter(old_cache_dir, mask);
> > 
> > Can you explain that works (does it?) and the code that you changed 
> > didn't work?
> >

You're right, I checked the calls to deleteFilesInDir and fixed the ones that I 
felt able to reproduce and show that they were fixed.  I reported the other 
calls to deleteFilesInDir that need to be fixed as subtasks of VWR-25861.  I 
didn't check the other uses of LLDirIterator because I thought they would have 
been fixed when STORM-477 was merged. I'll fix what I can and report the others.

Thanks


- Log


---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/315/#review724
---


On May 27, 2011, 1:04 p.m., Log Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/315/
> ---
> 
> (Updated May 27, 2011, 1:04 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a patch to fix the issues with clearing viewer caches documented in 
> VWR-25862. I removed the leading delimiter in the place where each of the 
> three caches are cleared.  I also removed the mac specific deleteFilesInDir() 
> method, which should have been removed for STORM-477. I removed unneeded 
> calls to getDirDelimiter() in llvocache.cpp.
> 
> 
> This addresses bugs vwr-25681 and vwr-25862.
> http://jira.secondlife.com/browse/vwr-25681
> http://jira.secondlife.com/browse/vwr-25862
> 
> 
> Diffs
> -
> 
>   indra/llvfs/lldir_mac.h UNKNOWN 
>   indra/llvfs/lldir_mac.cpp UNKNOWN 
>   indra/newview/llappviewer.cpp UNKNOWN 
>   indra/newview/lltexturecache.cpp UNKNOWN 
>   indra/newview/llvocache.cpp UNKNOWN 
> 
> Diff: http://codereview.secondlife.com/r/315/diff
> 
> 
> Testing
> ---
> 
> Test plan: https://jira.secondlife.com/browse/VWR-25862?#comment-262800
> 
> I built and tested on Mac, Windows and Linux and saw the correct behavior 
> when clicking the clear history button and the move cache button.
> 
> 
> Thanks,
> 
> Log
> 
>

___
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] Review Request: STORM-1103 Nearby sidebar minimap should be optional

[Altair Memo]

---
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/265/#review726
---

Ship it!


work fine on linux, nothing "evil" visible after some time of usage.

- Altair


On May 14, 2011, 1:07 p.m., Twisted Laws wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/265/
> ---
> 
> (Updated May 14, 2011, 1:07 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Patch makes the map in the Nearby people tab optional with a menu option in 
> the gear 
> menu.  Patch is XML only and resizing of the map is disabled 
> (user_resize="false" in 
> the layout_panels) as I could not find a way to easily save window sizes 
> purely in XML.
> Patch is in the repository of 
> https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103 as
> https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103/changeset/3455e79a14af
> and 
> https://bitbucket.org/Twisted_Laws/viewer-development-storm-1103/changeset/48b66643a4d1
> 
> 
> This addresses bug STORM-1103.
> http://jira.secondlife.com/browse/STORM-1103
> 
> 
> Diffs
> -
> 
>   doc/contributions.txt ee4d271eef9b 
>   indra/newview/app_settings/settings.xml ee4d271eef9b 
>   indra/newview/skins/default/xui/en/menu_people_nearby_view_sort.xml 
> ee4d271eef9b 
>   indra/newview/skins/default/xui/en/panel_people.xml ee4d271eef9b 
> 
> Diff: http://codereview.secondlife.com/r/265/diff
> 
> 
> Testing
> ---
> 
> Tested by exercising the gear menu option of "View Map" with the People tab 
> attached 
> and detached insuring the map appears and disappears properly.
> 
> 
> Thanks,
> 
> Twisted
> 
>

___
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] Minimum draw distance

[Oz Linden (Scott Lawrence)]

On 2011-06-06 12:37, Jonathan Welch wrote:
> I have been working on a draw distance slider and realized this would
> be a good time to have a discussion about what the lowest value you
> can set your draw distance to should be.
>
> If you have an opinion of why it should be lowered from what it is
> now, 64, please reply to this message with your reasoning.

There's a technical term for the above: "feature creep".

Let's see if we can get the feature implemented and accepted, and then 
we can worry about changing the range.

___
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] Minimum draw distance

[Lance Corrimal]

Am Montag, 6. Juni 2011 schrieb Oz Linden (Scott Lawrence):
> On 2011-06-06 12:37, Jonathan Welch wrote:
> > I have been working on a draw distance slider and realized this
> > would be a good time to have a discussion about what the lowest
> > value you can set your draw distance to should be.
> > 
> > If you have an opinion of why it should be lowered from what it
> > is now, 64, please reply to this message with your reasoning.
> 
> There's a technical term for the above: "feature creep".
> 
> Let's see if we can get the feature implemented and accepted, and
> then we can worry about changing the range.


the draw distance slider has been a given in dolphin viewer 2, 
restrainedlove, and any viewer that uses a starlight skin... and 
people are loving it.

bye,
LC

___
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] Minimum draw distance

[Trilo Byte]

Vertical slider for the win! :-)

I'm fine with existing settings, but given the large percentage of SL users 
that are using 'class 0' machines, I think a 48m or even 32m minimum would 
improve the experience and reduce the likelihood of crashing (especially at 
events or complex builds).

On Jun 6, 2011, at 9:37 AM, Jonathan Welch wrote:

> I have been working on a draw distance slider and realized this would
> be a good time to have a discussion about what the lowest value you
> can set your draw distance to should be.
> 
> If you have an opinion of why it should be lowered from what it is
> now, 64, please reply to this message with your reasoning.
> 
> Thank you,
> 
> -Jonathan
> ___
> 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] Review Request: Viewer cache size increase to 10GB.

[Tateru Nino]

Not that I'm not glad to see the maximum cache size increased, but the
cache cap was only very reluctantly increased to 1GB as the performance
of the system increasingly suffered as the quantity of cached objects
increased.

How did we solve this?

On 4/06/2011 9:32 PM, Oz Linden wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/318/
>
>
> Ship it!
>
> - Oz
>
>
> On June 3rd, 2011, 12:56 p.m., Log Linden wrote:
>
> Review request for Viewer.
> By Log Linden.
>
> /Updated June 3, 2011, 12:56 p.m./
>
>
>   Description
>
> This patch increases the maximum and default viewer cache size values. Due to 
> limitations in the size of the VFS, the 80/20 texture cache/VFS split is 
> maintained up to 5GB, then the remaining cache size is given to the texture 
> cache. This caps the VFS size at 1GB ( up from .2 GB ).  I made corresponding 
> changes to the XUI to allow the slider to increase to the new cache size 
> maximum.
>
> Bugfixes:
> * The reset cache location button will no longer tell the user that the cache 
> will be cleared if the cache is already in the default location.  Only the 
> notification was suppressed, the cache was never cleared by this button 
> unless the location changed.
> * The reset cache location button will now correctly clear the old cache when 
> it is reset back to the default location. 
> * I fixed an order of operation programming error in an llerrs log message in 
> the lltexturecache.cpp. This was showing wildly incorrect texture cache size 
> during a purge.
> * Code convention cleanup in llappviewer.cpp in initCache() and 
> lltexturecache.cpp
>
>
>   Testing
>
> I have built and tested on all three platforms.  The log files indicate that 
> the caches are being initialised with the correct sizes.
>
> *Bugs: * er-767 , er-883
> , er-883
> 
>
>
>   Diffs
>
> * indra/newview/llappviewer.cpp (9c0506d10226)
> * indra/newview/llfloaterpreference.cpp (9c0506d10226)
> * indra/newview/lltexturecache.cpp (9c0506d10226)
> * indra/newview/skins/default/xui/en/panel_preferences_setup.xml
>   (9c0506d10226)
>
> View Diff 
>
>
> ___
> 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] Review Request: Viewer cache size increase to 10GB.

[Monty Brandenberg]

On 6/6/2011 11:00 PM, Tateru Nino wrote:
> Not that I'm not glad to see the maximum cache size increased, but the
> cache cap was only very reluctantly increased to 1GB as the performance
> of the system increasingly suffered as the quantity of cached objects
> increased.
>
> How did we solve this?

Different cache for the most part (we have many caches).  This
change mainly affects the *texture* cache.  The general asset
VFS cache is still capped for technical reasons.  The scene caching
is unchanged.

We really want feedback on this on all platforms.  Load up the
texture cache, get your favorite regions in there, run around,
clear the cache, do it again, etc.  This work is being done
under VWR-25182.  Comments welcome and attach some jiras if you
encounter problems.

m


___
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