Multithreaded and GPU-accelerated 'Search' function

[Steven]

But there is an unwanted behaviour introduced with one of the latest builds, one scroll does not equal one line of artwork. The very last artworks are cut off in this version/ not fully visible.

i am not completely sure what you mean by that - would you mind posting a screenshot

also for you when it flickers, are you refering to when using the mouse wheel or dragging the scrollbar thumb with the mouse?

[ma_t14]

i am not completely sure what you mean by that - would you mind posting a screenshot

Nevermind, it seems to have corrected itself after restarting. I was talking about this:



For some reason that area was cut off so part of the bottom artworks was missing.

Edit:
Nope, still happening. I am not sure about this but I think in previous versions the zoom function scaled in such a way so that there never was any artwork cut off. I might be wrong though. Anyway, it's no big deal

also for you when it flickers, are you refering to when using the mouse wheel or dragging the scrollbar thumb with the mouse?

I was talking about scrolling with the mousewheel. But trying out the scrollbar now, it's similar. There is very small delay involved in loading the pictures

[lnminente]

@Ma_t14: I think you are referring to the constant rewriting of the artwork cache because of the setting "Fit artwork to the size of the panel". Maximize the window and the full cache has to be redone, restore the window rewrite the cache again, change a few pixels the width of the window then recalculate it again. I can't use the artwork layout for that reason and would recommend SSD users not enabling it too.

To test it well, you have to scroll the full artworks page from up to down to create for the first time the full cache, later change the window size to notice the differences when scrolling between enabling/disabling it.

[ma_t14]

@Ma_t14: I think you are referring to the constant rewriting of the artwork cache because of the setting "Fit artwork to the size of the panel". Maximize the window and the full cache has to be redone, restore the window rewrite the cache again, change a few pixels the width of the window then recalculate it again. I can't use the artwork layout for that reason and would recommend SSD users not enabling it too.

Is that because of the constant disk activity that will adversely affect the disk's lifetime in the long run? I don't use the artwork view much but yes when I do I have the fit artwork to the size of the panel enabled, but anyway I very rarely change the size of the window or change the zoom so it doesn't matter that much.

But yes, after disabling the "fit artwork to the size of the panel" option the drawing is almost instant. No matter how quickly you scroll it keeps up with the speed. Only for each immediate next line the drawing is visible

[Steven]

that sounds a bit strange to me and it shouldnt be rebuilding the cache if you are just scrolling (unless it is still in process of build the cache).
Anyway i am going to spend some time looking at this but it could be a few days

[lnminente]

@Ma_t14: Yep, for improving lifetime.

I made a screencast for showing how slow it becomes when width is changed:
Before 0'08 the cache was fully written so it was fast.
Since 0'08 the cache had to be redone because of the change of width when disabled the left panel

http://www.mediafire.com/download/tjcyglkbeu9tmtx/new.avi

[ma_t14]

that sounds a bit strange to me and it shouldnt be rebuilding the cache if you are just scrolling (unless it is still in process of build the cache).

Are you referring to me? I didn't say that that it is rebuilding the cache just from scrolling.

Or does it?

For Comparison
------------------------

MusicBee:

http://www.mediafire.com/?o9q11atg08k6uf8

JRiver:

http://www.mediafire.com/?ea821wc3dn7377v

p/s forgot to disable the sound

Probably JRiver uses some form of gpu acceleration, hm..

[ma_t14]

@Inminente

Wow seeing how bad it looks on your system mine seems like nitpicking. I almost feel bad now 

[Steven]

@lnminente - i fully expect the cache to be rebuilt if the panel size changes for any reason and "fit to panel" is enabled.
If all you are doing is scrolling (which is what i have understood that ma_t14 is doing) then the cache should not be rebuilt but of course if it was still in the process of rebuilding because the panel size changed then that would slow things down.
You have raised this as an issue several times - is there something i have missed in the point you are making other than you considering it not ideal behavior because in your use case the panel is changing each time you change tabs?

[lnminente]

@ma_t14: Yep, to the point of making it unusable :/

@Steven: That's right, and now you see why i asked for it so many times I thought it wasn't seen.
I'm only scrolling but use to maximize, and it's not a tab thing here is more the changes between restore window, maximize, or just show hide any side panel many times so that big lag doesn't lets me use the new layout we discussed here http://getmusicbee.com/forum/index.php?topic=3991.0
The point is the wish of adding the possibility of a fixed size in the new layout like in the old layout, so some of us could use it.

EDIT: For artwork cache rewriting i refer to the behavior with intensive cpu use for recalculating the new size thumbnails. When using a fixed size MB goes a lot faster because it doesn't needs to recalculate all the new thumbnails any time more, remembering them between restarts too.

[Steven]

i have made some changes that should behave better with flickering and also scroll faster:
http://musicbee.niblseed.com/V2_2/MusicBee_Exe_Patched.zip

I still dont think its as fast as j-river but also keep in mind when comparing it is only offering a fixed size artwork so i dont think its a fair comparison when "fit to panel" is enabled

[ma_t14]

i have made some changes that should behave better with flickering and also scroll faster:
http://musicbee.niblseed.com/V2_2/MusicBee_Exe_Patched.zip

I still dont think its as fast as j-river but also keep in mind when comparing it is only offering a fixed size artwork so i dont think its a fair comparison when "fit to panel" is enabled

Indeed, there is a huge improvement in the amount of flicker. Now for me, it's only if you scroll too fast that the artwork generation cannot keep up. In my setup I can't genuinely detect a difference in scrolling performance between the" fit artwork to size of panel" being enabled or disabled. Should this be the case? (Maybe it's because the artwork cache refresh is almost instant for me?)

All in all a an excellent update, thank you!

[Steven]

the artwork cache is only reset when the picture sizes are changed eg. when fit to panel is enabled and the panel size is changed.

[vivadavid]

I can also see a noticeable increase in speed. Congratulations, Steve!

[lnminente]

-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

There is a possibility where someone could have the panel width the same than an artwork so the cache shouldn't be redone. So i will leave the panel shown and only will change its width a bit to be sure it's redone for seeing the differences between fixed size and not.

This is how its seen in my computer with last update, both captures started with the cache fully rewritten before changing the left panel width:
http://www.mediafire.com/download/3422994hh63q7x2/fixed_size.avi
http://www.mediafire.com/download/64c5yv97q33jx1g/not_fixed_size.avi