Ultimate loading...

Ideas for improvements and requests for new features in XnView Classic

Moderators: XnTriq, xnview

Post Reply
User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Ultimate loading...

Post by Olivier_G » Fri Jan 13, 2006 12:30 am

Pierre recently implemented interruptable loading, but this hasn't solved everything yet. The other part needed is 'displaying image while loading'.

My suggestion using those 2 functions:
[1] User press Previous/Next key once (ie:press&depress): current operation is interrupted, new image is loaded immediately + displayed while loading.
[2] User press Shift+Previous/Next once: current loading is interrupted, what has been loaded is shown + new image is loaded immediately but will be displayed once completely loaded.
[3] User keep pressing Previous/Next: current operation (ie: loading/displaying current image) is continued up to the end + new image will be loaded up to the end before displaying, etc... until key is depressed.

What is it for?
[1] allows to quickly browse through images without having to wait for complete loading: you can skip to next one as soon as you recognize enough of the picture.
[2] allows instant switching to next image once loaded (looks better, easier comparisons between pictures).
[3] is for comfortable and fast screening through pictures.
(of course, you can immediately change behaviour by a simple key press, as explained before)

Comments are welcome.
Pierre: would it be possible to implement 'displaying image while loading' ?

Olivier
PS: I will then see how to integrate Buffer/Cache and EXIF orientation & HQ in all this...

User avatar
xnview
Author of XnView
Posts: 31607
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Ultimate loading...

Post by xnview » Fri Jan 13, 2006 7:52 am

Olivier_G wrote:Pierre: would it be possible to implement 'displaying image while loading' ?
Sorry but currently my Image IO library doesn't support this feature :-(
Pierre.

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Ultimate loading...

Post by Olivier_G » Fri Jan 13, 2006 12:12 pm

xnview wrote:Sorry but currently my Image IO library doesn't support this feature :-(
Too bad... :( ...Some users see this as a performance issue (ie: those "not fast enough when navigating through images")
=> Could your IO library be modified in the mid term to handle this?


Meanwhile, we can try 'better loading' ...with suggestions [2].
=> When you interrupt loading, can you use what has been loaded so far?

Olivier

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Ultimate loading...

Post by Olivier_G » Sat Jan 14, 2006 3:19 pm

Olivier_G wrote:=> When you interrupt loading, can you use what has been loaded so far?
Pierre, if this is actually possible with your library, it would be worth working on this issue for 1.82 as it is perceived as an important performance issue for a lot of users.
What do you think?

Olivier

Xyzzy
Posts: 652
Joined: Tue Nov 23, 2004 10:17 pm
Location: Poland

Post by Xyzzy » Sat Jan 14, 2006 11:46 pm

Yes, lot of users seem to like it "the traditional way".
Ie:
Image is displayed while it is being rendered. This way users can avoid delay when waiting for next image to appear.
I guess it will help users with slower PCs and using big images, so overall a significant improvement. Also I think a lot of people see it as a speed improvement, even if it actually slowed down browsing (they prefer user experience over speed&responsiveness).

There is another version of this request (if display-on-rendering is not possible): Display the already rendered part of image if request to skip to another image has been received from user and rendering is not yet complete.

There is also another related request- delay skipping to next image until complete image is displayed. This is useful for displaying flip-anims and for user who want be sure to see ALL images in file sequence.

EDIT: Another thing I haven't noticed earlier- please make fully rendered image display faster. (Ie. There's an image displayed and next one is already rendered by read-ahead function- make skipping to next image faster!).

EDIT2: Make an option to skip images as long as key/whatever is pressed, so in effect ignore input buffer contents if key/whatever is not currently pressed.

X.
Last edited by Xyzzy on Sat Jan 21, 2006 8:13 pm, edited 1 time in total.

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G » Sun Jan 15, 2006 11:49 pm

Just to check that we agree:
Xyzzy wrote:Image is displayed while it is being rendered. This way users can avoid delay when waiting for next image to appear.
...is [1] in my first message.
Xyzzy wrote:Display the already rendered part of image if request to skip to another image has been received from user and rendering is not yet complete.
...is [2] (and there is actually a need for [2] even if [1] is available: for quick and accurate comparison between Next/Previous images in order to avoid the continuous loading/displaying annoyance)
Xyzzy wrote:delay skipping to next image until complete image is displayed. This is useful for displaying flip-anims and for user who want be sure to see ALL images in file sequence.
...is [3]
Xyzzy wrote:Another thing I haven't noticed earlier- please make fully rendered image display faster.
... is here and here.


More to follow as soon as Pierre can confirm this:
When you interrupt loading, can you use what has been loaded so far?
...in order to suggest a better Loading/Displaying/Buffering solution.

Olivier

Xyzzy
Posts: 652
Joined: Tue Nov 23, 2004 10:17 pm
Location: Poland

Post by Xyzzy » Mon Jan 16, 2006 12:57 pm

Olivier_G wrote:Just to check that we agree:
Yes, requests are in fact the same.
Olivier_G wrote:
Xyzzy wrote:Display the already rendered part of image if request to skip to another image has been received from user and rendering is not yet complete.
...is [2] (and there is actually a need for [2] even if [1] is available: for quick and accurate comparison between Next/Previous images in order to avoid the continuous loading/displaying annoyance)
[/quote]

I think it is rather simply alternative to [1] and user preference.

IMO keep-behind function should complete rendering after read-ahead completed rendering of the next picture, and after pressing Back complete picture should be displayed. If it is possible to render whole image when user browses another image, why not do so?

The same if user skips back before current image is completed- read-ahead completes the image that was viewed just before the skip.

X.

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Update: detailled mechanism with Cache, EXIF rotation, HQ...

Post by Olivier_G » Tue Jun 27, 2006 3:33 pm

There should be 2 cache levels:
A. Full image loaded, with EXIF rotation (if necessary)
B. Image HQ resized for display (View or Preview) from A
-> Both caches should be created on the fly when loading the image at first (ie: load parts -> EXIF rotate (=add to A) -> HQ resize (=add to B)... continuously)
-> When changing Zoom/Size, A will stay in memory while B will be rendered directly from A.

[1] Previous/Next: display new image as soon as possible
- immediately display what is already available in B for new image and keep displaying on the fly until completion.

[2] Shift+Previous/Next: immediately display previous image and replace with new once completed
- immediately display what is already available in B for previous image
- start/continue creating A+B in the background for new image
- display new image once fully rendered

[3] Keep Previous/Next pressed: cycle through fully rendered images
- display new image as soon as it has been fully rendered
- then create A+B for the next image in the background until completion (and back to previous line)
Olivier

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Ultimate loading...

Post by Olivier_G » Tue Jun 27, 2006 10:54 pm

xnview wrote:
Olivier_G wrote:Pierre: would it be possible to implement 'displaying image while loading' ?
Sorry but currently my Image IO library doesn't support this feature :-(
I suppose this hasn't changed since? :?

Anyway...
:arrow: If it is possible to use what has been incompletely loaded, we could consider:
[2] Immediately display previous image and replace with new once completed
- stop loading previous image and use what is available (+skip EXIF rotation)
- resize (nearest neighbour) for quick display
- start loading+rendering new image and display once completed

Would this behaviour be possible, Pierre ?
Olivier

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G » Thu Jun 29, 2006 12:10 pm

Let's consider that 'display while loading' and 'partial display' is not possible for quite some time due to the Image IO library...

There is one improvement left, which has not been implemented in XnView so far but would be quite interesting: interrupt current loading.
The idea is that when XnView loads an image, you should be able to move to next file without having to wait for completion (just try that on a 10.000x20.000 JPEG, on a large RAW... or on a simple 5MP jpeg with a really old computer, and you'll see what I mean :mrgreen: ).

Mechanism:
- current image is being loaded
- user presses 'next'/'previous'
- loading immediately stops
- XnView starts working on the new image (cache or load/display)

There won't be any display, but XnView will be extremely reactive/fast. That's all good... :P
Olivier

User avatar
foxyshadis
Posts: 384
Joined: Sat Nov 18, 2006 8:57 am

Post by foxyshadis » Tue Jan 30, 2007 11:35 pm

That's a pretty good summary, and rather similar to what I was thinking earlier - I'm just afraid it would have to get more complicated to keep the memory footprint down. For instance, after moving away from a file, keeping the rendered version but dropping the original (if it's large?).

I hold comical up as the best implementation of caching that I've seen in free software, although the rest of it isn't that great. It has a separate layer that all requests for rendering files (to 100% and to fullscreen size) go through, so that the cache can manage its own memory, resize algorithms, and so on. The layers that call it tell it what to open, queue up pre-renders, and so on. The way it's implemented now, I obviously can't see it, but I'm guessing it was kind of hacked in there without extensible support.

As an extension to the 'interruptable loading', it'd be nice if resizing was interruptable so that if you were holding the 'next' button down it'd show you nearest neighbor renderings of stuff that's loadable. (A little nicer than comical's blank pages, if a little more disk-heavy.) Perhaps simply disabling HQ until they stop getting interrupted. But all that's just a nice tweak, not a killer feature like interruptible scrolling in general is.

All this is just the opinion of an outsider, don't put too much weight on it if there are better ways percolating.

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G » Wed Jan 31, 2007 10:48 am

foxyshadis wrote:I'm just afraid it would have to get more complicated to keep the memory footprint down. For instance, after moving away from a file, keeping the rendered version but dropping the original (if it's large?).
My first idea was to reduce HD/CPU work, but having now played with some huge images I can see the advantage of your proposal in some situations (drop original +reload when needed).
The main issue I see is when XnView starts to use a lot of RAM (ex: lots of thumbnails...) and adds buffering of large images over that. An optional overal RAM limit to handle buffering behaviour could be interesting.
foxyshadis wrote:it'd be nice if resizing was interruptable so that if you were holding the 'next' button down it'd show you nearest neighbor renderings of stuff that's loadable.
'Resizing' is interruptable: you can skip an image being rendered and in 'delayed HQ' you can actually see the LQ before moving to next image (and skipping HQ). What you suggest is probably more about the behaviour related with keeping 'next' pressed. In [3], I suggested to "fully render the image before going to next image", but your suggestion to skip HQ in this particular situation is actually a very good one.
foxyshadis wrote:All this is just the opinion of an outsider, don't put too much weight on it if there are better ways percolating.
Foxyshadis: your feedback is always elaborate, very well thought and right to the point... so it's really a pleasure to get some feedback from you! :D
Olivier

Post Reply