[sldev] Cache politics: performance vs obfuscation

Dahlia Trimble dahliatrimble at gmail.com
Tue Jun 10 12:08:20 PDT 2008


Only if your goal is interopability with external programs. If that is the
goal, it should be stated. If the goal is to improve the performance of the
viewer, then that goal should be weighed against user needs.

On Tue, Jun 10, 2008 at 11:57 AM, Laurent Laborde <kerdezixe at gmail.com>
wrote:

> 2008/6/10 Dahlia Trimble <dahliatrimble at gmail.com>:
> >
> > Further, noone is going to be inducted into the programmer hall of fame
> for
> > writing a binary file to a disk. If you want to do something that is a
> > benefit to the community, develop a method that improves cache
> performance,
> > saves network bandwidth, and doesnt alienate a large portion of the user
> > base. If you want to make a cache browser/exporter, then call it that. I
> see
> > no reason that a standardized image format would necessarily be the
> highest
> > performance choice for a cache.
>
> There is one good reason to use a standardized image format and it's
> directly related to performance.
> I widely used open format have tons of coder working on the libraries
> to use this format and work on optimisation/performance.
>
> A library used by millions of users, including large corporate
> company, is most likely highly optimized, stable, reliable and secure.
> Just take a look at the discussion about "commercial jpeg2000
> librarie" vs "openjpeg2k librarie".
>
> that's why we don't even talk about trying to improve the decoding
> libraries performance anymore : it was done already, and by external
> coders.
> If LL develop a custom image format, it will cost a lot of ressource
> to work on optimization, etc ...
>
> --
>  F4FQM
> Kerunix Flan
> Laurent Laborde
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080610/9eb317fc/attachment.htm


More information about the SLDev mailing list