On Sun, Sep 19, 2010 at 3:13 PM, Aidan Thornton wrote:
> On 9/19/10, Argent Stonecutter wrote:
> > Perhaps Tateru was referring to the prim data changing (eg, geometry)
> while
> > the prim UUID stays the same. I don't think the viewer makes any
> assumptions
> > about prims being unchanged from
On Sun, Sep 19, 2010 at 3:27 PM, Altair Sythos wrote:
> On Sun, 19 Sep 2010 13:16:25 -0700
> Kelly Linden wrote:
>
>
> > * Rezed objects are given a new UUID (though they will still
> > reference the 'original asset id' for some internal tracking server
> > side)
>
> yes but cache was hinted for
On Sun, 19 Sep 2010 13:16:25 -0700
Kelly Linden wrote:
> * Rezed objects are given a new UUID (though they will still
> reference the 'original asset id' for some internal tracking server
> side)
yes but cache was hinted for etxtures, what happen to same textures
copied or shared to others?
I
On 9/19/10, Argent Stonecutter wrote:
> Perhaps Tateru was referring to the prim data changing (eg, geometry) while
> the prim UUID stays the same. I don't think the viewer makes any assumptions
> about prims being unchanged from session to session, so that's not something
> that would need to be
> On 2010-09-19, at 12:49, Oz Linden (Scott Lawrence) wrote:
>> On 2010-09-19 10:21, Tateru Nino wrote:
>>
>> I believe he was referring to the fact that a UUID does not always refer
>> to the same inworld object. There are instances where an object UUID
>> will be used more than once.
>
>>
> Th
On Sun, Sep 19, 2010 at 12:53 PM, Tateru Nino wrote:
>
>
> On 20/09/2010 3:49 AM, Oz Linden (Scott Lawrence) wrote:
> >On 2010-09-19 10:21, Tateru Nino wrote:
> >> I believe he was referring to the fact that a UUID does not always refer
> >> to the same inworld object. There are instances whe
On 20/09/2010 3:49 AM, Oz Linden (Scott Lawrence) wrote:
>On 2010-09-19 10:21, Tateru Nino wrote:
>> I believe he was referring to the fact that a UUID does not always refer
>> to the same inworld object. There are instances where an object UUID
>> will be used more than once.
>
> Those would
On Sun, Sep 19, 2010 at 12:12 PM, Ponzu wrote:
>
> True. But there are actually UUID algorithms that accept a very low
> probability of repeating a UUID.
>
LL cant afford to have repeats. It would break a lot.
http://wiki.secondlife.com/wiki/UUID
--
Daniel Smith - Sonoma County, California
On Sun, Sep 19, 2010 at 1:49 PM, Oz Linden (Scott Lawrence)
wrote:
> On 2010-09-19 10:21, Tateru Nino wrote:
>> I believe he was referring to the fact that a UUID does not always refer
>> to the same inworld object. There are instances where an object UUID
>> will be used more than once.
>
>
> Th
On 2010-09-19 10:21, Tateru Nino wrote:
> I believe he was referring to the fact that a UUID does not always refer
> to the same inworld object. There are instances where an object UUID
> will be used more than once.
Those would be bugs, by definition.
On 2010-09-19, at 09:21, Tateru Nino wrote:
> On 20/09/2010 12:17 AM, Argent Stonecutter wrote:
>> On 2010-09-18, at 20:57, Altair Sythos Memo wrote:
>>> On Sat, 18 Sep 2010 20:53:21 -0500
>>> Argent Stonecutter wrote:
On 2010-09-17, at 12:51, Altair Sythos Memo wrote:
> There aren't tool
On 20/09/2010 12:17 AM, Argent Stonecutter wrote:
> On 2010-09-18, at 20:57, Altair Sythos Memo wrote:
>> On Sat, 18 Sep 2010 20:53:21 -0500
>> Argent Stonecutter wrote:
>>> On 2010-09-17, at 12:51, Altair Sythos Memo wrote:
There aren't tools to assure to an agent him cached texture is sti
On 2010-09-18, at 20:57, Altair Sythos Memo wrote:
> On Sat, 18 Sep 2010 20:53:21 -0500
> Argent Stonecutter wrote:
>> On 2010-09-17, at 12:51, Altair Sythos Memo wrote:
>>> There aren't tools to assure to an agent him cached texture is still
>>> one cached the teleport before...
>> Not needed. T
On Saturday 18 September 2010 9:51:22 pm Argent Stonecutter wrote:
> I honestly think that going to a straight squid-style cache for textures
> would so improve the user experience that worrying about extra features
> like "preferred places" would become irrelevant.
I have managed to get a local s
On Sat, 18 Sep 2010 20:53:21 -0500
Argent Stonecutter wrote:
> On 2010-09-17, at 12:51, Altair Sythos Memo wrote:
> > There aren't tools to assure to an agent him cached texture is still
> > one cached the teleport before...
>
> Not needed. Textures are static. UUIDs are never re-used.
prims ch
On Sat, 18 Sep 2010 20:51:22 -0500
Argent Stonecutter wrote:
> I honestly think that going to a straight squid-style cache for
> textures would so improve the user experience that worrying about
> extra features like "preferred places" would become irrelevant.
in fact... now "HTTP" textures allo
On 2010-09-17, at 12:51, Altair Sythos Memo wrote:
> There aren't tools to assure to an agent him cached texture is still
> one cached the teleport before...
Not needed. Textures are static. UUIDs are never re-used.
___
Policies and (un)subscribe inform
I honestly think that going to a straight squid-style cache for textures would
so improve the user experience that worrying about extra features like
"preferred places" would become irrelevant.
___
Policies and (un)subscribe information available here:
> > * Let the local operating system deal with the file caching. If you
> > have 4+ gig of system memory, let the OS manage it for caching
> > frequently accessed world data.
>
> if i have 4+GB i use a ramdisk as cache... XD
>
Wow. I am getting VERY old and senile. WHY oh why I didn't think of
I think this is actually a crucial first step to cache improvement. The
performance of this system would be an extremely useful baseline. For
instance I'd love to be able to toggle between saving jp2 and raw w and
w/out mipmap. There can be performance benefits to storing content
compressed o
On 09/17/2010 01:08 PM, Oz Linden (Scott Lawrence) wrote:
>On 2010-09-17 12:56, Ponzu wrote:
>> But some users want to be able to override this. I want a certain
>> location to always load fast, even if I rarely visit it.
>>
>> User story: I want to mark certain locations as "Fast Loading"
On Fri, Sep 17, 2010 at 10:51 AM, Altair Sythos wrote:
> On Fri, 17 Sep 2010 10:17:27 -0700
> Daniel Smith wrote:
>
>
> > A passive means of ranking a cache would be:
> >
> > 1) did the user already have an LM here?
> > 2) did an object just give a user an LM to this place?
> > 3) did the user j
On Fri, 2010-09-17 at 13:08 -0400, Oz Linden (Scott Lawrence) wrote:
> On 2010-09-17 12:56, Ponzu wrote:
> > But some users want to be able to override this. I want a certain
> > location to always load fast, even if I rarely visit it.
> >
> > User story: I want to mark certain locations as "Fast
On Thu, 16 Sep 2010 18:36:50 -0500
Dale Mahalko wrote:
> * Decode all JPEG2000's once, to all levels of mipmap scale, and write
> the raw RGB mipmaps to disk as individual files (UUID+mipscale.bmp),
> discarding the source JP2's.
high load, and next time u see same object the viewer should downl
On Fri, 17 Sep 2010 10:17:27 -0700
Daniel Smith wrote:
> A passive means of ranking a cache would be:
>
> 1) did the user already have an LM here?
> 2) did an object just give a user an LM to this place?
> 3) did the user just proactively create an LM?
>
> These are 3 distinct cases. #1 and #
On Fri, Sep 17, 2010 at 9:56 AM, Ponzu wrote:
> But some users want to be able to override this. I want a certain
> location to always load fast, even if I rarely visit it.
>
> User story: I want to mark certain locations as "Fast Loading" even
> if I do not visit them very often. This should
On 2010-09-17 12:56, Ponzu wrote:
> But some users want to be able to override this. I want a certain
> location to always load fast, even if I rarely visit it.
>
> User story: I want to mark certain locations as "Fast Loading" even
> if I do not visit them very often. This should override the
But some users want to be able to override this. I want a certain
location to always load fast, even if I rarely visit it.
User story: I want to mark certain locations as "Fast Loading" even
if I do not visit them very often. This should override the automatic
behavior of the system.
On Fri,
I think that maybe "places" should have scores of how often they are
visted to determine how long the cache of that place is stored. So
since every login you start at home it would have a high score
therefore the cache would be stored for a longer period of time. Same
goes for places you visit ofte
Yes gutting the cache helps a lot. So does dumping a copy of the cache
into a folder with the name of a sim, and on change to a
non-contingous sim swapping where the cache points to so that suddenly
the cache from the last visit to that sim is used.
No, it's not compliant, because the most efficie
General concensus and *working code*.
Go for it.
On Thu, Sep 16, 2010 at 9:12 PM, Brandon Husbands wrote:
> You could technically watermark the images and have the display code just
> remove that mark.
> If it cant find the mark its considered corrupt.
>
> On Thu, Sep 16, 2010 at 6:45 PM, JB Han
On 9/16/2010 7:36 PM, Dale Mahalko wrote:
> This cache would much simpler than the layered mess of caches
> currently used, and it would give a speed boost over the constant JP2
> to RGB mipmap decoding and discarding that is in place now. Decode
> once and don't ever do it again.
Speaking for my
You could technically watermark the images and have the display code just
remove that mark.
If it cant find the mark its considered corrupt.
On Thu, Sep 16, 2010 at 6:45 PM, JB Hancroft wrote:
> > This viewer would get blacklisted before it ever got out the door.
>
> Because... it would be non-
> This viewer would get blacklisted before it ever got out the door.
Because... it would be non-compliant in some way?
On Thu, Sep 16, 2010 at 7:36 PM, Dale Mahalko wrote:
> I just don't have the motivation for it myself, but I would really
> like it if a 3rd party developer would gut out LL's
I just don't have the motivation for it myself, but I would really
like it if a 3rd party developer would gut out LL's texture cache and
eliminate the VFS, and replace them with a simple disk cache that
writes all assets in raw format, with files named by UUID on disk.
* Decode all JPEG2000's once
On 9/16/2010 1:17 PM, Daniel Smith wrote:
> Greetings Daniel from Daniel --
>
> It would be good to know from the Lindens as to the negative effect from
> having a cache size that is too big.
A few quick points:
- There isn't a single cache. There are actually multiple
persistent and
On Thu, Sep 16, 2010 at 9:44 AM, Daniel wrote:
> As a user I would like to see an improved cache in order to have a
> better Second Life experience. The types
> of improvements that would lead to a better experience include:
>
> * A higher cache size limit. This would let me save more data and
I propose a slight modification...
As a user, I want to be able to choose some number of places that load more
quickly, and am willing to trade some disk space to make this happen. This
list of places may, or may not, be based on visit frequency, favorites or
personal selection. (I may want a part
Strictly speaking I think you have the stories and tasks reversed here.
As a user I'd like to be able to use a greater portion of my available disk
to improve the SL experience.
* Task: Improve the cache system to allow larger caches
As a user I'd like the places I visit most often, like my 'home
As a user I would like to see an improved cache in order to have a
better Second Life experience. The types
of improvements that would lead to a better experience include:
* A higher cache size limit. This would let me save more data and speed
up rez times, and also put less
load on the serv
40 matches
Mail list logo
