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.
Viewer slow as hell
Moderators: helmut, XnTriq, xnview
Viewer slow as hell
Last edited by Danny on Wed Jun 27, 2007 9:18 pm, edited 1 time in total.
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
Re: Viewer slow as hell
Right, sometimes, there is 4 resampleDanny 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.
Do you want a test version with the bug fixed?
Pierre.
Re: Viewer slow as hell
Sure, why not? Just PM me a link or something.xnview wrote:Right, sometimes, there is 4 resample
Do you want a test version with the bug fixed?
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
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.
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.
Last edited by Danny on Thu Jun 28, 2007 1:16 pm, edited 1 time in total.
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
Yes, i can perhaps take the same picture loaded in preview for view!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.
Pierre.
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?xnview wrote:Yes, i can perhaps take the same picture loaded in preview for view!
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
I've send you a link to a new test version!Danny wrote: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?xnview wrote:Yes, i can perhaps take the same picture loaded in preview for view!
Pierre.
No new PM here. Or is it the same zip as before?xnview wrote:I've send you a link to a new test version!
Last edited by Danny on Thu Jun 28, 2007 1:50 pm, edited 2 times in total.
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
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.
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.
Last edited by Danny on Thu Jun 28, 2007 2:01 pm, edited 3 times in total.
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
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?
Maybe there are other places in XnView where "double work" is occurring?
John
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)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.
Pierre.
Hmm... I don't know. I'm no programmer.xnview wrote: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)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.
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.
Get the bugs fixed, THEN start adding features. It sucks, but someone has to do it.
-
foxyshadis
- Posts: 395
- Joined: Sat Nov 18, 2006 8:57 am
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.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?