[fixed] coverflow severely slows down facadeload (2 Viewers)

[tourettes]

I like the idea of loading the images in the background, or more specifically on another lower priority thread that can have its speed reduced before the main render loop - not sure how to do this in MP. I notice that this would provide the load effect that I see on my Mac - the cover flow on a Mac loaded all the frames immediately (low overhead) and the images appear as they are loaded; the performance of the cover flow never degraded. Getting the load out of the render loop is the key. Have any ideas how to do this?

We should have some generic threaded loading for all gfx items, not just to try to tweak cover flow only. Unfortunately such big changes cannot be done for 1.2.0, but instead they should be targeted for possible future versions. It is just too much risk of regression (even for making that canhe for cover flow only) and after all we are already in feature freeze.

 

[Guzzi]

AW: Re: coverflow severely slows down facadeload

Getting the load out of the render loop is the key. Have any ideas how to do this?

Unfortunately the is far beyond my capabilities, so probably best someone of the teamdevs more familiar with those parts can suggest.

 

[Guzzi]

AW: Re: coverflow severely slows down facadeload

We should have some generic threaded loading for all gfx items, not just to try to tweak cover flow only. Unfortunately such big changes cannot be done for 1.2.0, but instead they should be targeted for possible future versions. It is just too much risk of regression (even for making that canhe for cover flow only) and after all we are already in feature freeze.

I agree, that a generic solution would be the best and gives most profit to the whole presentationlayer of MePo - probably removing the most often mentioned shortcoming of lowresponsive GUI - but even if in featurefreeze, why not trying to improve the planned 1.2 features (CF) to be as good as possibe - could be a good step one for a generalized solution, if a good working solution can be done for coverflow.

I would appreciate if some rules/hints could be given and Andy would give it a try (could even make a debugswitch to disable that to be "fully safe") - but that's up to the teamdecision...

 

[Jay_UK]

Hi there,

I'm sure this has been covered in this thread (about the less than ideal way coverflow draws the screen - my simple terminolgy), but under normal usage of my HTPC coverflow seems ok for my collection of music (not that many albums - I used shares view), but when I connect to my HTPC via RDP (for admin/testing purposes) it appears to show how coverflow works (draws objects) - ie the screen refresh is a lot slower. From this it looks like the the objects are drawn in a weird order and an inefficient way? (seems really bad)

Might just be me though....

Thanks

J.