ShowImage read-ahead cache does not move along with navigation

[stippi]

When browsing large images, the positive effect of the read-ahead cache is immediately noticable, since the next two images after launching ShowImage with the first one will open instantly. However, the cache does not immediately begin to load the next images after navigating forward. After the first two images have displayed, navigating to the next images will always suffer the delay of loading them before they display.

[axeld]

Not sure what you are doing, but it certainly works fine over here.

[stippi]

My revision is hrev39661. I have a folder with 536 images between 2 and 7 MB each. The Tracker folder is open and sorted by Name. I double clicked a random image from far down in the list, ShowImage opens. When pressing the down arrow on the keyboard to navigate in ShowImage, the next two images open instantly. Every following image has the loading delay, no matter how long I looked at the previous image. What are you doing? :-)

[axeld]

Pretty much the same thing, just that my folder has 796 images ;-)

I guess the best thing to do would be to add some debug output to ImageCache.cpp. I'm afraid there is no debug output yet at all. Can you find the time for that? Most interesting would be when new threads are created, and when new images are started/finished with loading.

Are you using a GCC2 or GCC4 build?

[stippi]

Hopefully I can find some time soon. My build is a GCC4 based hybrid, and it's a clean build, not update-all'd.

[axeld]

There are a couple of ShowImage bugs filed that only affect the GCC4 version - I don't know what I did wrong there.

[halilpk]

(GCI-2011 Participant)

Haiku revision: hrev42211 still a bug. It is caching just two files which are opened last . System: Haiku hrev1-alpha3 on VMware workstation 8 on windows 7 32 bit

[hometue]

(GCI-2012 Participant) Haiku revision: hrev44702. Still a bug, only valid on bigger images. When testing on duplicates of an image 5.81mb big, only the next image will be cached, after that ShowImage will not attempt to cache the next image after I navigated to the cached image. It is noticed that the previous image viewed will be cached. System: Haiku R1-alpha4 on Virtualbox 4.1.20 on windows 7 64 bit

[leavengood]

In contradiction to the GCI students above, this does not seem to be an issue to me. I turned on the tracing which is now in the ShowImage ImageCache, and I see the cache faithfully doing its duty.

I could also test on GCC4 to see if this issue is specific to that compiler, but certainly for GCC2 the ImageCache works fine.

[leavengood]

On second thought, if you move quickly, the caching strategy seems to get messed up.

Also it is annoying that the progress window will only work with the RAWTranslator which is the only one that supports the /progressMonitor and /progressMessage IO extensions.

[Janus]

Stippi. How much ram do you have? how many core do you have? Can you specify the resolution of the images (resolution is important not filesize)?

These are parameters that can explain why the cache doesn't move.

The cache keeps at least 2 images in memory. if this images are greater than ~memory/7,5 the cache stops precaching.

[stippi]

Janus, I can't remember on which system I observed the bug and if I still have that. Could be that it was on a laptop with 8GiB RAM. The images were large, I can try to reproduce the issue, I have a faint memory with which images it happened.

[Janus]

I can reproduce this with big images. Increase the memory for the cache can help, but this doesn't solve the problem. We can always find a bigger image. :-(

[axeld]

Not sure why this would be a problem: the reason why there is a cache is to speed things up. If you have enough memory, it could be put to use, if not, then it won't be -- exactly as it should, and the hardware allows for.

If the limits are to tight, it's not a big issue to make them more flexible, is it?

[Janus]

With "this doesn't solve the problem" I meat that anyone can reopen this ticket with some big images...

How much memory do we assign to ShowImage? Now it is 1/5 of the memory, but the insertion try to guess the size of the new image (~memory/7,5).

I found another strange behavior. I don't know if this worth to modify the cache: sometimes the preloaded images are loaded before the requested one.

how to reproduce this (In a single core machine):

• put in a folder a small image and a very big one.
• open the small one.
• ShowImage took a very long time to open (time to load the big image + the small one)

This happen when the loading thread is scheduled after the insertion of the preloaded images in the queue

[axeld]

That looks like a new issue, please open a ticket for this, this definitely deserves to be fixed. I also noticed that the caching can have negative issues when using it via USB (very slow to open the first image).

Anyway, back to the topic, I couldn't find where the size is guessed, but 1/5 of all memory doesn't really make that much sense. Why not just use, say, up to 85% of free memory instead? It would be nice to have weakly referenced bitmap areas, but I'm afraid such a mechanism does not exist yet :-)

[Janus]

Replying to axeld:

That looks like a new issue, please open a ticket for this, this definitely deserves to be fixed. I also noticed that the caching can have negative issues when using it via USB (very slow to open the first image).

If your machine is single or dual core this can be the case I was describing. I'll open a new ticket.

[Janus]

Replying to axeld:

Anyway, back to the topic, I couldn't find where the size is guessed,

This is the "guess" part :

((fCacheMap.size() < 4 && fCacheMap.size() > 1
	&& fBytes + fBytes / fCacheMap.size() > fMaxBytes)