Delay when switching quickly forth/back with HQ & Cache

Olivier_G · Post by **Olivier_G** » Tue Dec 19, 2006 2:13 pm

With following Options ON:
- View>Misc>'Keep current image in cache' AND 'Read one image ahead'
- Preview>'Use high quality' (also set HQ for Browser's fullscreen)
- Fullscreen>'Use delayed...' (use a small value)

Open an image A in Browser's fullscreen (wait for next image to be cached) then switch quickly Next/Previous image: you will see a small delay (0.3s?) before XnView actually starts to display previous image (ie: A in Cache) when it should be immediate (first pass).

For information: unsetting 'HQ' OR 'Read ahead' solves the issue... so it seems to be a timer used when both 'HQ' and 'Read ahead' are used.
(try without 'HQ' to see how quick it should react)

XnView 1.90 <x>

foxyshadis · Post by **foxyshadis** » Tue Dec 19, 2006 2:33 pm

I believe this is actually an artifact of the HQ (bilinear) resize algorithm's speed. If you test with 500x500 images, there should be no such delay, since the resize is almost instant. Without HQ, resize is basically instant no matter how large the image. Unsetting read-ahead alone doesn't change the behavior for me.

The read-ahead/back cache currently only stores the decoded full image, not the resized version. I'd suggest, and I know others have in the past, for both decoded and resized versions to be kept, in order to make browsing even more responsive even with slower HQ resizers.

(But then you'd start running into memory issues for a lot of people; since I have 2 gigs it wouldn't bother me, but some folks use xnview with 128 megs or less. Creating a program-wide cache that detects memory pressure would be best, or swapping will break all the benefits. I thought about specifics quite a bit, but I decided against posting a thread if it'll just annoy Pierre.)

Olivier_G · Post by **Olivier_G** » Tue Dec 19, 2006 2:52 pm

foxyshadis: set 'Use delayed...' ON with "0" to actually see the difference (LQ first, HQ second).
-> first pass LQ (ie: of delayed HQ) has that small delay.
-> normal LQ (ie: no High quality) is immediate.
(LQ calculations are the same, caching too)

I agree about the buffering of HQ... but that's not the topic here, because I don't want to see it 'postponed' immediately...

Edit: you have to try with large images to experience that small delay... so it's not just a simple timer as I thought...

Olivier_G · Post by **Olivier_G** » Fri Dec 22, 2006 2:56 am

Still the same issue with Beta 6.

I describe again (with more info):
- View>High Quality Zoom = ON
- Fullscreen>Use delayed = ON (put 0 value)
- View>Misc>'Read ahead' and 'Keep current' = ON
- Put 2 large images A and B (ex: 6MP) and a third image C to trigger 'read ahead'.

Open A in Browser's fullscreen (wait for B to be in cache).
- If you switch rapidly A->B->A (ie: Next/Previous with keyboard) you get a small delay after B. Do it several times to check it.
- Stay on B. If you switch rapidly B->A->B (ie: Previous/Next) you don't get any delay.
(you won't get any delay if you uncheck HQ, 'Read ahead' or remove image C. This delay seems to be the time needed to perform the second HQ pass, although resize is an interruptible thread and command should be immediate)