Alternative, non-locking Thumbnail generation Method

[highend]

You pull (by letting the master send it back) it from the slave. But Thomas is right, it doesn't solve his problem

[autocart]

But Thomas is right, it doesn't solve his problem

Which is that creating the thumbnails from big images just takes too long. Period. Right, Tom?
At first you wrote

So my request would be the following:
I would love to have a kind of hybrid. All thumbnails should be created when entering a folder, but somehow in a non-blocking background thread, that allows me to already work in the folder and for instance look at textures with right-mouse-blowup etc. So that background thread should also run with low priority, so it doesn't block other things.
...
As a little extra, the thumbnail generation thread could also focus on the currently visible files first, before continuing with the ones outside the view window, spreading maybe up and down equally in both directions, centered around the current view, so that no matter in which direction you scroll, you should always have thumbs waiting already... :-)

But then you summarized it this way:

Yeah, but I don't think this is what we want.
If creating the thumbs takes 10 minutes, I'm no better off than at the beginning, or am I?

Cheers,

Tom

So, it really is the speed of thumbs generation by itself, right?

[admin]

I know that it should be backgrounded. And it will be backgrounded. One day...

[ThomasHelzle]

No, it's not mainly the speed, not really (or only part of it).

If I browse the folder in XNviewMP, sure large images take a bit to show up, but during that time, I can move around just fine and the visible files will be prioritised (XNview is much faster at this btw. - feels like about ~10x faster (maybe it's time to retire the old FastPictureViewer? It doesn't seem to see any updates anymore and isn't really that fast anyway?)).

In XY on the other hand, I can't do anything while it creates the thumbs, so it's totally non-interactive.
Even just scrolling is totally erratic and jerky.

So:
a.) creating thumbs in XY takes very very long, yes.
b.) this also blocks interaction almost completely.

So b makes a even worse...

Cheers,

Tom

[autocart]

Ok, so the theoretical custom coded solution discussed throughout this thread should help with (b).

However, it would probably be tedious to code and resolve all bugs and keep it updated. I know that I would not want to do it.
Maybe klownboy has a lot of free time and wants to upgrade his script accordingly?
Otherwise we all have to wait for Don:

And it will be backgrounded. One day...

EDIT:
klownboy, Don promised to help you:

Not 100% sure (I'm not a scripter), but if it's not possible yet, I will make it possible.

Either way, fun thread.

[klownboy]

And with copydata you are able to run a script in another XY instance.

I'm not sure as XY currently stands you'd ever have a very fluid operation at least not what ThomasHelzle wants. Of course the thumbnail database is the same regardless of the instance. I haven't tried using SC copydata for this situation, but I noticed that a move out of and back in the subject folder in the first instance is currently necessary to see the results of the thumbnail creations taken place in the 2nd instance.

I say that because I've ran some tests with "Show cached thumbs only" checked with a bunch of existing already cached thumbs in a folder. I added about 55 additional images to the folder. I then ran a background script to build the additional thumbnails in a 2nd instance. When done (2nd instance finished), a normal refresh (not a thumbnail refresh) will not result in seeing the newly created thumbnails added to that folder, but as soon as you move out of and back into the folder you will see those newly created thumbnails already generated (by the second instance). Obviously that isn't desired or very fluid.

[ThomasHelzle]

That is what I feared to happen.
Thanks a ton klownboy!

[autocart]

When done (2nd instance finished), a normal refresh (not a thumbnail refresh) will not result in seeing the newly created thumbnails added to that folder

Well, what happens on a thumbs refresh?

EDIT:
Oh, never mind.

Refresh Thumbnails

Refreshes all thumbnails in the current list, no matter the setting of "Show cached thumbnails only" and "Create all thumbnails at once".

Recreates the thumbs cache of the current folder (when thumbs caching is enabled).

[klownboy]

Yeah, a thumbnail refresh (CID #501) would kind of defeat the purpose. I was surprised (well maybe not) that it took movement in and out of the folder to see the results of the newly created thumbnails by the 2nd instance. I first tried to simply change the view from "thumbnail" to "list" and back to "thumbnail" and that didn't do it. In a script so much is dependent on whether the folder has a FVS and tab settings in generating thumbnails (i.e., detecting whether there is a FVS or not, moving to a folder in itself will start generating thumbs when you have an FVS but not if you don't). In the Thumbnail Maintenance script I had to relocate in the foreground before running #501 in the background instance or change views. It was very awkward to say the least.

[autocart]

I just found out a reason for it. Even after updating the thumbs cache in the 2nd instance, doing a ::thumbscacherename <curpath>, <curpath>; in the 1st instance, the status bar still says: "path was not found in thumbnails cache".
It is like the 1st instance is working with an internal copy of the thumbnails cache and it must be re-initiated in the 1st instance.

[klownboy]

...it must be re-initiated in the 1st instance

Yes, the 1st instance has to be woken up to the refreshed thumbnail cache made in the 2nd instance. Moving out and back into the folder does that. Maybe Don could do something which could rectify that but in the end I still don't think it's going to provide the fluid operation that ThomasHelzle was looking to get.

[ThomasHelzle]

Yeah, that's basically what I get when I let the thumbnails fully generate before I try to do anything in the folder.
So that isn't really an improvement over what I get when I use the normal "create all thumbnails" method...

But thanks, at least I'm now sure I didn't miss anything ;-)

Cheers,

Tom

[eil]

As i remember in some other topic Don said there are some plans for making "sub-routine app" - this is an exact situation where it could be useful = on thumbs creation need, don't freeze current XY, but send task to back-app.

[admin]

That "sub-routine app" is already there, misleadingly called "XYcopy.exe". Now I just have to teach it making thumbnails. I mean, one day...

[PeterH]

Does that mean, it would either copy or create thumbnails at a time?
(As long as it is only one task / thread?)