XnView Software

I'm using High Quality in XnView. ACDSee has no options to set quality, so it's very possible they lower the quality to increase the speed. On a 1280x1024 screen, a 3000x2000 digital photo is probably going to look the same in any quality, now that I think of it.

However, the slight lag in full screen viewing in XnView is something I can easily live with for XnView's other features. I'm quite happy now that I've fixed the directory display lag, so this is not something I'm worried about.

Again, thanks for your quick replies!

Full screen file viewing photo-to-photo is instantaneous with ACDSee, but takes at least 1 second with XnView.

for me, this is the most annoying thing on xnview. i think that's also the reason for other users to switch back to acdsee (again:).
in its category, xnview is really the best what you can find. i appreciate devolopers for their hard work. but it's not good idea to overlook essential things like these. thanks for reading guys

ali wrote:

Full screen file viewing photo-to-photo is instantaneous with ACDSee, but takes at least 1 second with XnView.

for me, this is the most annoying thing on xnview. i think that's also the reason for other users to switch back to acdsee (again:).
in its category, xnview is really the best what you can find. i appreciate devolopers for their hard work. but it's not good idea to overlook essential things like these. thanks for reading guys

I couldn't agree more: I use ACDSee (Version 5 before 3) on a daily basis since years i nearly tried hundreds of different ImageViewers none of them could beat ACDSee in this most essential aspect.
So get ACDSee on a PC-machine (on a Mac its slow as the rest) and see it how fast it is!
The Quality is a little bit lower but still perfect to judge and evaluate pictures.
Everything else is much better with XnView but in this most essential aspect its lacking far behind so i still use ACDSee.
So please solve this Problem and i would be very happy to pay/donate for XnView.

ali wrote:

Full screen file viewing photo-to-photo is instantaneous with ACDSee, but takes at least 1 second with XnView.

for me, this is the most annoying thing on xnview. i think that's also the reason for other users to switch back to acdsee (again:).
in its category, xnview is really the best what you can find. i appreciate devolopers for their hard work. but it's not good idea to overlook essential things like these. thanks for reading guys

In view mode or from browser? With or without Read ahead option?

In view mode or from browser? With or without Read ahead option?

it doesn't matter what settings i have

ali wrote:

In view mode or from browser? With or without Read ahead option?

it doesn't matter what settings i have

Could you send me a sample to test?

Marco:
Going (effectively, so that I can recognise every pic) in view mode from pic to pic via mousewheel through a folder with 62 images (with the average filesize mentioned above). With xnview it took me around 1 minute. With ACDSee around 17 seconds (If I want, I can go from the first to the last pic in 5 sec).

I have thousands of images in hundreds of folders. Viewing them, sorting them etc. So, a fast imageviewer is essential to me.

let's say you have larger pictures (2000+). if you want, for example, to switch from the first picture to the last, you'll get lost.

again, i don't know how they do it in acdsee - you can scroll from picture to picture without delays.
in xnview, you have to wait until the whole picture is in cache. then you can, without any delay, go to next one. in acdsee,
you don't have to wait for that process, you can "fly through" the pictures to the last one you want to see. i mean, the picture will show partially, so you know where you are in directory and you don't have to wait for that slow caching process (llama's opinion:)

they say "browse large numbers of high-resolution images at the blink of an eye". that's it. i recommend downloading a trial version of acdsee just for testing purposes.

i don't know if sending you a sample has a meaning. i would say it's a "feature".

thanks.

...

ali wrote:Again, i don't know how they do it in acdsee - you can scroll from picture to picture without delays. in xnview, you have to wait until the whole picture is in cache.
In acdsee, you don't have to wait for that process, you can "fly through" the pictures to the last one you want to see. i mean, the picture will show partially, so you know where you are in directory and you don't have to wait for that slow caching process (llama's opinion:)

Right: I think this the most important performance issue in XnView right now (and probably a 'stopper' for a lot of people).

XnView always want to end the current action (ex: display preview/view entirely...) even if the user has pressed a key to skip it and start a new one (ex: display next image).
=> XnView should show images while loading, and be able to stop and move immediately to the next image if the user decides so.

Olivier
PS: this issue has been regularly mentionned in other threads about performance...

the "read ahead" feature should help it (that's why i suggested it to XnView from ACDSee!). it should load next image to memory, while you're viewing current one, then it should appear instantly.. unfortunately there are some unknown problems with it, that it doesnt quite work as expected (well, not as good as in ACDSee anyway )

Hi,

I noticed that speed difference too, and i think it may be really due to the topic "XnView should show images while loading".
Following scenario:
in viewer press a series of pgdown for "next image"
- acdsee shows a series of black screens but you reach quickly eg. image #30 which you are just searching for
obviously they don't show the images while loading so they don't have the repaint overhead if you want to "skip" an image you just don't want to see
- xnview shows the images (including scrollbars ..) while loading and you can step to a next image not so fast
I really don't know which method is better but would tend to suggest: let the user decide by an option which method fits best to his needs.

2 remarks
- for me the option "read an image ahead = on" does not speedup the scrolling but slows it down
- the effect mentioned above is most noticeable at "fit window to desktop,all", not so much with "fit image to height"

Best Regards,
klaus2

I made a test here too.
Got 35 Images with about 900kb size on a 2.66 GHz machine with 1GB Ram.

xnview really seemes to take a little longer than ACDSee 3. But at a closer look the advantage of ACDSee also results in the behavior to show the image while loading. It loads from top to bottom and xnview shows the image in on "frame" plop! but not until its loaded completely.

But at all the delay is really really acceptable. On the other hand: If you watch an image sequence the loading from top to bottom in ACDSee is only annoying.

That's correct. However there's a noticeable speed difference especially
with "fit image to desktop" (not so much with "fit image to height").
What you see is the additionally paint activity that acdsee does not do if not needed.

My vote is: let the user decide how he wants to have it
(paint when ready or skip paint when meanwhile next image is aquired).
Xnview waits until the image is built; acdsee does not (press pgdown a lot,
you'll see black windows); that in my opinion makes the impression of speed difference.

I'm not quite sure why "fit to desktop" is so much slower than "fit image to height";
i hope it is not to the horizontal window adjustment (i opened a thread to require
that feature).

klaus2

I would love the following behaviour:
- XnView loads image continuously (or by packets)
- It resizes (and rotates, according to EXIF+options) on the fly what has been loaded and shows it
- If user changes the image in between, XnView skips immediately the current image and starts to render the next image
(moreover, it should be linked to the cache of images by using the same technique: display what has already been loaded/rendered in the cache and continue displaying directly from there)

Olivier

Yes, I agree - it's very important to skip current operation if user pressed "next"/"previous" etc