XnView Software

I think, the CACHE Feature isn't necessary - it only wastes a lot of diskspace, esspecially if users have a lot of images. Additional, I couldn't see, that xnview was faster with this feature.
I think this feature should be deactivated by default - there are too much programs today which waste so much discspace. I think in this case, you can simply save space.

If someone wants, he can turn this feature on and can waste some diskspace.

andy wrote:I think, the CACHE Feature isn't necessary - it only wastes a lot of diskspace, esspecially if users have a lot of images. Additional, I couldn't see, that xnview was faster with this feature.
I think this feature should be deactivated by default - there are too much programs today which waste so much discspace. I think in this case, you can simply save space.

If someone wants, he can turn this feature on and can waste some diskspace.

I strongly disagree. If users have the choice: Speed or diskspace, most users would clearly go for the speed. With XnView you actually have an option to deactivate the cache, with many other programs you have no choice at all. And be sure that many programs use caching, starting from your webbrowser, not ending with MS Explorer on XP (caching of Thumbnails by placing a hidden file "thumbs.db" in each folder).

You can easily experience the cache when browsing a folder for the second time. The first time building up the thumbnails may take a while, but the second time it's just a flash and you see all the thumbnails.

Well with current prices of BIG hd drives (here on spain 200gb is less than 100€ with taxes) i don't think that disk space is a trouble.

What really would be worth thinking of is some aging and/or limit. At the moment I have the feeling that the cache just fills up and caches thumbnails regardless of their size (even 300x300 pixels). If there isn't a limit for cache size, already, a limit should be introduced. And from time to time XnView should do some optimization automatically (perhaps ask user first).

I suggest these options:

[x] Use maximal [X] MB for cache (then, first delete oldest items)

[x] Automatically delete items in cache older than [X] days

...or better [x] Automatically delete items in cache not used for more than [X] days

Dreamer wrote:I suggest these options:

[x] Use maximal [X] MB for cache (then, first delete oldest items)

[x] Automatically delete items in cache older than [X] days

...or better [x] Automatically delete items in cache not used for more than [X] days

Ok, but for a future release.

xnview wrote:

Dreamer wrote:I suggest these options:

[x] Use maximal [X] MB for cache (then, first delete oldest items)

[x] Automatically delete items in cache older than [X] days

...or better [x] Automatically delete items in cache not used for more than [X] days

Ok, but for a future release.

So for 1.80 RC2? (just kidding ) Thank you!

Also you can change the zip compresion by 7zip.

Aokromes wrote:Also you can change the zip compresion by 7zip.

7zip is under GPL, not free.

xnview wrote:

Aokromes wrote:Also you can change the zip compresion by 7zip.

7zip is under GPL, not free.

It is free, but maybe too free LOL

But actually you're wrong.
LZMA SDK is actually somwhat quad-licensed.
1.) GPL
2.) Common Public License
3.) "Unmodified Source" License
4.) Proprietary license (to buy)

Especially 3.) is good for you.

SPECIAL EXCEPTION: Igor Pavlov, as the author of this code, expressly permits you to statically or dynamically link your code (or bind by name) to the files from LZMA SDK without subjecting your linked code to the terms of the CPL or GNU LGPL. Any modifications or additions to files from LZMA SDK, however, are subject to the GNU LGPL or CPL terms.

SPECIAL EXCEPTION allows you to use LZMA SDK in applications with closed code, while you keep LZMA SDK code unmodified.

(But actually even under GPL it is possible to keep "main code" closed while just GPLing the gluecode/wrappers to the application )


PS:
But I doubt that LZMA compression would give much smaller files for pictures that are compressed anyway.

I want to add, that newer computers are so fast that they don't really need a cache feature. I have a duron 1000 mhz and a 80 Gbyte Harddisk and I don't see a difference between activated and deactivated cache-feature.

And older computers aren't fast enough to use the cache-feature...

Furthermore, program-size could be reduced and perhaps the whole program could be a little bit faster if removing cache-feature at all.

Think about it

andreasm82 wrote:I want to add, that newer computers are so fast that they don't really need a cache feature. I have a duron 1000 mhz and a 80 Gbyte Harddisk and I don't see a difference between activated and deactivated cache-feature.

And older computers aren't fast enough to use the cache-feature...

Furthermore, program-size could be reduced and perhaps the whole program could be a little bit faster if removing cache-feature at all.

Think about it

Again, I strongly disagree. A hard disk is about 100.000 times slower than RAM. Unless the cache is really badly implemented, it will definitely be a performance improvement and needed. On my computer (P4, 2.4 GHz) caching makes a BIG difference when viewing images.

You can turn caching off if you think it's better for you. If you want to continue discussion please make some tests with and without caching first and see the difference.