[sldev] Cache politics: performance vs obfuscation

[Dahlia Trimble]

spelling correction: inter-operability

On Tue, Jun 10, 2008 at 12:08 PM, Dahlia Trimble <dahliatrimble at gmail.com>
wrote:

> 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/1b67d384/attachment.htm