Image Display Issues on Win XP
rcozens at pon.net
Tue Dec 20 09:59:04 CST 2005
>Yes, that is the basic idea... whatever is going to be the least demanding
>on system memory will work best. Use actual thumbnails when possible; load
>images into memory only when needed.
Thanks for the additional info. One question: Does alwaysBuffer
really mean anything if an image is added directly into a stack [as
opposed to adding it by reference]? It seems to me an image included
in a stack file is always in memory once the stack is opened.
>Another method to consider is to keep the images out of the stack; encrypt
>the images on disk (encrypt command); and decrypt them (decrypt command) as
>they are loaded. This will make them slightly larger on disk and use more
>memory, but it will keep your stack small and stable.
Yes, it is a possibility.
>Keep in mind that without extreme workarounds (i.e., using certain DirectX
>routines), images are never really secure on a computer; a press of the
>Print Screen button will put that picture on the clipboard. By embedding
>them in a stack or encrypting the image files on disk, you're only making it
>a little less difficult to access them.
I understand. It's a lot like anti-hacker protection: it's never
going to be 100% effective, and there comes a point of diminishing
returns where the additional protection is not worth the programming effort.
But here's a larger [& somewhat off topic] question:
Suppose one is creating a portfolio of photographic
art. Furthermore, assume the "original" photographs are sold as
"one-of-a-kind" photos, with the proviso that the original electronic
photo image is "destroyed" after a print is made. How does one
provide a likeness of the image (in 5 MPix detail) without providing
access to the image file itself?
Rob Cozens, CCW
Serendipity Software Company
Vive R Revolution!
More information about the use-livecode