XnView Software

If you choose any kind of fitting option and switch from browser to viewer it takes forever to finally have the image being displayed.

Part of the problem seems to be that the image is first being loaded at 100% zoom at the top left corner of the viewer. Then the interface is being put into place, and only then the image is being resampled to its intended zoom factor.

In other words: you seem to be doing things more than once here. You should overhaul your routines as it seems. I don't want to call names here, but other programs can do that a lot faster.

Danny wrote:If you choose any kind of fitting option and switch from browser to viewer it takes forever to finally have the image being displayed.

Part of the problem seems to be that the image is first being loaded at 100% zoom at the top left corner of the viewer. Then the interface it being put into place, and only then the image is being resampled to its intended zoom factor.

In other words: you seem to be doing things more than once here. You should overhaul your routines as it seems. I don't want to call names here, but other programs can do that a lot faster.

Right, sometimes, there is 4 resample
Do you want a test version with the bug fixed?

xnview wrote:Right, sometimes, there is 4 resample
Do you want a test version with the bug fixed?

Sure, why not? Just PM me a link or something.

I've just tried out the test version you sent me. It's much better now - about twice as fast. While opening an 4.5MB JPG took almost 4 seconds before, it now takes a little more than 2 seconds. So good work there.

But you still load an image at 100% zoom into the viewer. Doesn't that cost time unnecessarily? The image is being loaded into RAM in the browser already, right? Then you switch the interface to the viewer, display the image (at 100% - why?), and then resample it so it fits into the viewer, right? I bet there's still some redundant work being done.

I hate to be a dick but.... the 'other program v5' is still quicker. It needs less than 1 second for the same picture. I think they're somehow streaming it though.

Danny wrote:I've just tried out the test version you sent me. It's much better now - about twice as fast. While opening an 4.5MB JPG took almost 4 seconds before, it now takes a little more than 2 seconds. So good work there.

But you still load an image at 100% zoom into the viewer. Doesn't that cost time unnecessarily? The image is being loaded into RAM in the browser already, right? Then you switch the interface to the viewer, display the image (at 100%), and then resample it so it fits into the viewer, right? I bet there's still some redundant work being done.

I hate to be a dick but.... the 'other program v5' is still quicker. It needs less than 1 second for the same picture. I think they're somehow streaming it though.

Yes, i can perhaps take the same picture loaded in preview for view!

xnview wrote:Yes, i can perhaps take the same picture loaded in preview for view!

Well, i can't say since i neither know how your program really works nor their program. But if you think of something - go for it. Displaying pictures is probably the most basic and important function of XNView, so it ought to be quick, right?

Danny wrote:

xnview wrote:Yes, i can perhaps take the same picture loaded in preview for view!

Well, i can't say since i neither know how your program really works nor their program. But if you think of something - go for it. Displaying pictures is probably the most basic and important function of XNView, so it ought to be quick, right?

I've send you a link to a new test version!

xnview wrote:I've send you a link to a new test version!

No new PM here. Or is it the same zip as before?

Danny wrote:

xnview wrote:I've send you a link to a new test version!

No new PM here. Or is it the same zip as before?

yes

Ok. It now doesn't load the same image again, if it's already being shown in the browser's preview area - like you said. That benefit is lost though, if the preview area is hidden, evidently. Still an improvement though.

Why is loading an image so slow anyway? What exactly is taking so long? It takes less than a second to load 4MB (or maybe 30MB for a decoded JPG) of data into RAM, so that can't be it.

Either way: compared to the original version it's a big improvement now, so thank you for that.


On a sidenote: it might be nice to have the possibility to switch off hq-resampling for the browser's preview area like you can do for thumbnails. But that's not very important.

I just want to add my support here for any approach/process that speeds up XnView. Recent versions seem slower (to load thumbs, for instance) than XnView used to be. Yes, I'm using larger thumbs than previously and the images I load are much bigger than they were "back then" (typically 2.5k x 3.5k for the majority) but my hardware is much faster, too (even the disks), so things ought to "equal out".

Maybe there are other places in XnView where "double work" is occurring?

JohnFredC wrote:Maybe there are other places in XnView where "double work" is occurring?

Not in thumbnails loading...

Danny wrote:Why is loading an image so slow anyway? What exactly is taking so long? It takes less than a second to load 4MB (or maybe 30MB for a decoded JPG) of data into RAM, so that can't be it.

I don't know, for loading a jpeg i use the same library as other software... (I/O on windows is often slower than other OS)

xnview wrote:

Danny wrote:Why is loading an image so slow anyway? What exactly is taking so long? It takes less than a second to load 4MB (or maybe 30MB for a decoded JPG) of data into RAM, so that can't be it.

I don't know, for loading a jpeg i use the same library as other software... (I/O on windows is often slower than other OS)

Hmm... I don't know. I'm no programmer.

Another thing just occured to me. In comparison to "that other program" switching from one image to the next is also slow. It takes distinctly longer than one second two skip through images (again, 4MB JPGs), while skipping happens almost immediately in "that other program".

And i'm talking about having "read ahead" and "cache behind" enabled. It doesn't make a difference really. Don't you cache the hq-resampled version? It appears as if the resampling is being invoked everytime you switch images. That'd definately be a waste of resources. It should cache the resampled image, not the base image.

Another thing i just noticed is that, if i disable delayed HQ for large images, switching works overall faster.

A pleasant surprise has been how fast XNView has become handling JPEG2000 files over time. In other programs (Faststone Viewer for example) it can really take forever to process them - and so was the case about a few months ago for XNView. But right now there's barely a difference anymore.

Danny wrote:Another thing just occured to me. In comparison to "that other program" switching from one image to the next is also slow. It takes distinctly longer than one second two skip through images (again, 4MB JPGs), while skipping happens almost immediately in "that other program".

And i'm talking about having "read ahead" and "cache behind" enabled. It doesn't make a difference really. Don't you cache the hq-resampled version?

No, that's been a request for a while though. It also has to cache the base in addition to any resampling in case the user changes the view mode.