[sldev] P2P/Squid Web Textures: Enabling Greater Quality Images - draft 2

[dale at daleglass.net]

On Sat, Jul 07, 2007 at 09:05:10AM -0700, Dzonatas wrote:
> >First we see what it looks like, and based on that we could see what
> >could be done. Other possiblities include tweaking compression quality,
> >or allowing uncompressed uploads but charging more for them.
> >  
> 
> Even if there is an extra charge, it still doesn't immediately help the 
> sim network performance.
Ok, but let's not confuse issues here.

If you want quality, then let's do quality: Get people to submit images
for comparison. AFAIK, JPEG 2000 has a configurable quality level, just
as the usual JPEG. This probably can be tweaked without any server
changes. Then we can do tests, and judge the results based on quality.
IMO it's meaningless to talk about the quality of something without
providing any proof of it.


If you want network performance, then let's talk about that as well, but
in that case it's weird to consider things like sculpties at all, as
they're really tiny in comparison to everything else. Here we should be
talking about 1024x1024 textures instead. Just one of them is 256 times 
larger than a 64x64 sculptie texture.


> 
> >
> >IMO, if you want to reduce bandwidth usage that's a very good goal to
> >have, but the logical thing would be to start from the BIG things, not
> >from the tiny ones.
> >
> >For example, how about *reducing* quality? Make the price dependent on
> >texture size and compression quality. This would give the people an
> >incentive to avoid upload things that are larger than necessary.
> >  
> That has been suggested for awhile even by LL. It would be another 
> sim-side change... more things to support... more work piled on LL.
Why server change?

Charging for textures is actually client-side IIRC. Compression is
client-side. It can really be done without involving the grid at all,
unless there's something server-side that checks that the texture has
been uploaded with specific parameters.



> 
> >There's no reason why you couldn't accept uncompressed images only up to
> >64x64.
> >  
> 
> Thought about that, also. It still doesn't reduce cost on the sim 
> network, and it would be another sim-side change.
Assuming there's anything at all server-side, it'be tiny. Patching
something like:

if (image.isLossless()) reject();

To something like:

if (image.isLossless && image.width > 64 && image.height > 64) reject();

This is overly simplistic of course, but I doubt it'd require anything
very complicated server-side.


> 
> How do we avoid sim-side changes until they are actually needed? Is 
> there anything to prevent the steps being done externally?
But P2P will require server-side changes as well.

Who will run the tracker for instance? You will need LOTS of them to
cope with the load SL currently has. This can't be something running
from a cheap box in somebody's basement, and I doubt a single box could
handle it (not to mention reliability problems).

IMO, P2P would need to be organized by LL, with a server-side tracker.
Which means sim-side changes.

> 
> 
> -- 
> Power to Change the Void
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070707/876ef19d/attachment.pgp