Multithreaded and GPU-accelerated 'Search' function

[Steven]

-The computing of the cache is much faster now as it uses my two cores now.
-But not as fast as not redoing the cache setting a fixed size

when you have fixed size pictures the cache is reset only if you change the picture scaler ie. set a new fixed size. In that circumstance the cache needs to be rebuilt. Similarily for "fit to panel" the cache is rebuilt because the picture size changes if the panel is resized. But once the cache needs to be rebuilt then the process is exactly the same irrespective of the setting.
Setting fixed size pictures generally means the cache is not rebuilt.
I have noticed that when changing tabs, where the left panel is collapsed in one tab and not the other causes the panel to be unnecesarily resized. So i will correct that

edit:
i have also made a small improvement when "fit to pictures" is enabled - i dont notice it on my computer but if you have a SSD drive it might make more of a difference (one file deletion per picture is not done)

[Steven]

this has the change:
http://musicbee.niblseed.com/V2_2/MusicBee_Exe_Patched.zip

[Thorbjorn]

Wow, making the sorting function multi-threaded made a huge difference here! It's really fast now.
Thank you Steven!

[Steven]

there was a resizing bug when collapsing the left or right panel
http://musicbee.niblseed.com/V2_2/MusicBee_Exe_Patched.zip

[lnminente]

when you have fixed size pictures the cache is reset only if you change the picture scaler

Yep, that's precisely why i have to stick with the uglier but faster old layout.
No SSD here just said it because of the avoidable rewritings, results almost the same than the videos posted above.

By other side i have noticed the artworks are cached at original full size, so i have some .dat files at 1600x1300px, while the maximum size of the artwork view is 340x340px. Is that a bug? I think a big improvement would be caching them at 340x340px instead of having them twice in my computer and when needed a bigger size just take it from the source.


Capture showing the size of my cached artworks: http://s23.postimg.org/nyiqrlswb/Untitled.png

[Steven]

those files are used for other places (now playing panel, album and tracks view) where the displayed size can potentially be much larger. The ".dats" the files for the artwork layout.
I am not planning to spend any more time on this

[Steven]

i have made one further change so the cache is no longer rebuilt on resizing the panel - however the first use of the new version will rebuild the cache so will be slow the first time. After that, the rebuild process should only happen when the picture scaler is moved.
I will make it available later today

[Steven]

this has the change:
http://musicbee.niblseed.com/V2_2/MusicBee_Exe_Patched.zip

[lnminente]

We are getting near, i have deleted the artwork cache, all the .dats files are smaller than 60kbs. By the moment i don't have any .dat file.
Noticed you changed from jpg to png recently, that increases the thumbnail size but gives better interpolation results while avoiding redoing the cache.

I thought investigating image browsers would help here, so i remembered ACDSee used only one file to caching the thumbnails, i took a look to my actual image browser XnView and found it also uses only one file. It is a SQL file which i uploaded here with the content of the artwork cache from MB http://www.mediafire.com/download/1k39ay5wprc9vg4/XnView.db

I don't use J-river, could someone tell us if it uses only one file for image caching?

[ma_t14]

How is the performance for you now?

[lnminente]

A bit faster than before, but really slow compared with XnView for example.
Before capturing the video i restarted windows and artwork caching was done (upgraded system to 4gb)
Results using latest update: http://www.mediafire.com/download/rh5cgrcp3rwikk6/new_layout_130803.avi

Edit: This is XnView for comparison with more than 600 pics of the same size
NSFW (paranoic pics i keep) http://www.mediafire.com/download/t8s8kvbb1vt6ngb/xn.avi

[ma_t14]

What are your system specs? So you main problem is that artwork cache refresh takes too long but otherwise scrolling is fine?

I have a 2 year old laptop (only thing I added was an ssd) and everything runs pretty smoothly (even artwork refresh is almost instant, I don't even notice).

[Steven]

from the video thats extraordinarily slow - infact i cant believe you said using fixed width pictures is ok as that is almost the same in terms of processing now as compared to "fit to panel" when scrolling.
The only thing i can think of is perhaps you are not using 32 bit colours on your display settings? If you are using 16 bit colours then that might be a reason and perhaps i could do something about that otherwise i doubt i can do anything more.

edit:
just as an experiment could you try this version to see if its any different when doing a small amout of scrolling:
http://www.mediafire.com/?c7tbniaauj4f5ae

[lnminente]

@Mat14: The video is at 25fps but it doesn't shows as fluent as it should, the real behavior is softer than the videos show but we can get an idea of the thumbnail loading.

I have an http://www.cpubenchmark.net/cpu_lookup.php?cpu=Intel+Core2+Duo+T7250+%40+2.00GHz&id=1000
Upgraded recently RAM to 4GB DDR2
and a sata HD with  6.8MB per second for sequential write,  291.5MB per second for sequential read, and 107.5MB per second for random access.

I think scrolling is the culprit here, as it takes always too much cpu.

@Steven: Yep, the old layout and the new one works very similar now. While when using the new layout i have to use the title below the artwork for seeing the titles in a more reasonable waiting time. It's MB what is so slow compared with XnView. I'm doing some comparisons and i see XnView does a very few use of CPU when scrolling (will post a video to show it).

The truth is all the processes showing images are really slow with MB in my machine, i noticed it in the theater mode when artist pic changes. So it might be the process for drawing the pics.

Not noticeable changes with that version Steven, in fact i got the fourth freeze when scrolling since this feature started. MB doesn't shows a message error but completely freezes and have to close the process from the task manager.

Is usual MB using a lot of CPU when scrolling or could be something bad in my installation?

[lnminente]

Forgot to say i'm using 32 bit colors, 1280x800 at 60Hz with an ati mobility radeon HD 2400

Here a video showing the CPU use, note one core is almost 100% capturing the video:
http://www.mediafire.com/download/xjxsqccrbyb5ebx/cpu.avi