[sldev] Cache politics: performance vs obfuscation

Dahlia Trimble dahliatrimble at gmail.com
Tue Jun 10 11:34:49 PDT 2008


If I wear my "as a user" hat, I'm not sure a small increase in cache
performance is going to sway my opinion of the software. If, wearing my
"content creator" hat , I see that there are no obstacles to anyone getting
full permission access to my content, I'll probably assume that there is no
benefit to me to spend a lot of time developing quality content. Sure, I can
right click on an image in a web browser and save it, but if I were browsing
a stock photo site I would only be able to save a watermarked thumbnail, and
I wouldnt get the nice high resolution image until I agreed to the TOS and
paid them, so the internet browser analogy doesn't hold water in that case.
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.

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

> 2008/6/9 Jason Giglio <gigstaggart at gmail.com>:
> >
> > Who cares?  A small utility anyone can write in a few hours can do this
> > today.
> >
>
> *NOT* anyone, just "any coder willing to spend some time on it".
> Writing a software to decode the current cache isn't that much complex
> than decoding a XOR'd texture cache.
>
> A lot of software protection can be unlocked replacing a JNZ with a
> JNC instruction, extremly simple, but most people simply can't do
> that.
>
> But the question is : does the current obfuscation have any impact on
> cache performance ?
> As far as i remember, we agreed that the current cache have a very
> little impact on performance and most of the cpu time is spent in
> decoding j2c.
>
> The current cache is working, have a very little perfomance impact,
> and provide enough protection against script-kiddies.
> The probleme is in the jpeg2000 decoding performance.
>
>
> --
> 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/3732fca8/attachment-0001.htm


More information about the SLDev mailing list