Ultimate loading...

[Olivier_G]

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...

[xnview]

Pierre: would it be possible to implement 'displaying image while loading' ?

Sorry but currently my Image IO library doesn't support this feature

[Olivier_G]

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

[Olivier_G]

=> 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]

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.

[Olivier_G]

Just to check that we agree:

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.

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)

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]

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]

Just to check that we agree:

Yes, requests are in fact the same.

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.

[Olivier_G]

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_G]

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...
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_G]

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 ).

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...

[foxyshadis]

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.

[Olivier_G]

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.

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.

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!