[fixed] coverflow severely slows down facadeload (1 Viewer)

[jameson_uk]

OK makes sense now

 

[Guzzi]

AW: coverflow severely slows down facadeload

So should someone add it to mantis to not forget about it?
I am personally fine for the moment by disabling coverflow in the related skinfiles, but for a future release I think it should be solved ...

 

[arion_p]

It appears that coverflow control adds 2 animation controls for every item added in the list. As if that was not enough, it also forces those 2 animations to allocate resource (load textures) as soon as each item gets added (as opposed to when AllocResources is called on the coverflow itself).

This means that adding 10.000 items also adds 20.000 controls and tries to load 20.000 textures. I do not know how this could be implemented but to me this is clearly a bad design.

 

[Guzzi]

AW: Re: coverflow severely slows down facadeload

[...] it also forces those 2 animations to allocate resource (load textures) as soon as each item gets added [...]

If I remember right when I stepped through the code, that was the part taking most of the time - so allocating/loading the textures later (as it's done e.g. with filmstrip) instead of when adding the item might solve the performanceissue - but you're right, it means oc some rework of the coverflowimplementation ...

 

[ajp8164]

Hi all -

I agree - this is a bad design and needs to fixed, duh. Since I wrote CF I'll have a look; at first glance it looks as though FS uses a "rolling" set of 30 frames which it reuses regardless of the number of items in the list (good idea ;-) To implement this idea the number of preset available frames may have to be specified in the skin file (with 30 as the default) since the number of CF cards may exceed 30 based on the geometry specified and the number of items in the collection.

I'll change CF to implement the frames in the same manner. The frames are the only images that are appear to be causing this problem (but I'm glad to be corrected - only looked at it for 10 minutes or so).

 

[Guzzi]

AW: coverflow severely slows down facadeload

Hi Andy,
good to see you stepped into this - as you probably know the code best
The easiest probably is to follow the different approaches in facadeView.Add(item) - see https://forum.team-mediaportal.com/...erely-slows-down-facadeload-90020/#post686744 and compare what happens when adding FS vs. CF.
If I remember right, FS doestn't load even the 30 frames when an item is only added - this happens only if FS is visible and needs to be rendered - but I might be wrong, it's long ago I looked into the code. Anyway, I am very happy you look into it, because it's a really nice new view and I look forward to reactivate it.

 

[ajp8164]

Re: AW: coverflow severely slows down facadeload

Hi Andy,
good to see you stepped into this - as you probably know the code best
The easiest probably is to follow the different approaches in facadeView.Add(item) - see https://forum.team-mediaportal.com/...erely-slows-down-facadeload-90020/#post686744 and compare what happens when adding FS vs. CF.
If I remember right, FS doestn't load even the 30 frames when an item is only added - this happens only if FS is visible and needs to be rendered - but I might be wrong, it's long ago I looked into the code. Anyway, I am very happy you look into it, because it's a really nice new view and I look forward to reactivate it.

That's my strategy! Looks like FS loads the animations during FinalizeConstruction(). When an item is added nothing really happens in FS (a collection is updated). I'll see if I can get this done over the next few days. I want people to use and showcase CF!!

 

[ajp8164]

Committed a fix for this issue (SVN 27059). Also created a mantis issue (3286) to track.

As has been discussed in this thread the main problem was caused by a bulk creation of GUIAnimation objects during facade load time. A side effect of the original design was that the total number of GUIAnimation objects created exceeded the number necessary for good performance. The fix implements a lazy create/allocate of GUIAnimation objects in the render loop. In addition the fix only creates/allocates enough GUIAnimation objects to support the rendering of visible coverflow cards (e.g., if only 20 cards are rendered then only 20 GUIAnimation objects are created even if the card collection is much greater than 20). This is the same strategy that the Filmstrip control implements.

While looking through the coverflow and filmstrip implementations I notice that filmstrip frees memory on "cards" that are not rendered in the window - e.g., if FS only renders 5 cards and the card collection has 100 items then the other 95 cards (those that are not rendered) have their GUIImages released at the bottom of the render loop. As the FS scrolls the new cards coming into view have their GUIImages created and allocated just in time. While I not sure of how the performance of FS is affected by this I notice on my test system that CF is severely affected with this memory management strategy. CF is sensitive to the render timePassed for proper animation and continuous GUIImage creation/allocation degrades the presentation. The result is that CF does not implement the memory management strategy as in FS. This means that the CF view uses more memory since all of the card GUIImages remain in memory while the view is rendered (each card GUIImage is created/allocated lazily so you may notice degraded animation performance while your scroll right the first time).

My concern is that for very large collections the amount of memory being used may reach levels that severely affect the overall performance of MP -- I'm open to strategies that could help reduce memory use while maintaining animation performance.

 

[Guzzi]

AW: Re: coverflow severely slows down facadeload

Hi Andy,
thanks for the patch - didn't yet compile and test, so just some thoughts about it yet...

While looking through the coverflow and filmstrip implementations I notice that filmstrip frees memory on "cards" that are not rendered in the window - e.g., if FS only renders 5 cards and the card collection has 100 items then the other 95 cards (those that are not rendered) have their GUIImages released at the bottom of the render loop. As the FS scrolls the new cards coming into view have their GUIImages created and allocated just in time. While I not sure of how the performance of FS is affected by this I notice on my test system that CF is severely affected with this memory management strategy. CF is sensitive to the render timePassed for proper animation and continuous GUIImage creation/allocation degrades the presentation. The result is that CF does not implement the memory management strategy as in FS. This means that the CF view uses more memory since all of the card GUIImages remain in memory while the view is rendered (each card GUIImage is created/allocated lazily so you may notice degraded animation performance while your scroll right the first time).

This strategy sounds good to me - and it should imho also be taken into consideration for FS, as it imho improves userexperience

My concern is that for very large collections the amount of memory being used may reach levels that severely affect the overall performance of MP -- I'm open to strategies that could help reduce memory use while maintaining animation performance.

What do you think about defining just a "max cardpool" for the allocations you keep in memory? e.g. 500 or 1000 - checking this should be "cheap" cpuwise and if you get beyond it, you drop the first allocated (FIFO). Maybe even dropping them in a block (e.g. 10 or 100) might be good for GUI performance, because it's not required then for each movement in the GUI.

This way you can limit the max memconsumption regardless of number of items while keeping good renderperformance in presentation - and practically a user won't have thousands of items and scrolling through all of them from beginning to end and viceversa.

optional:
If you want to further improve it, you could load the animations nearest to current position "idle threaded" in the background, so most probably the cards already be allocated/available for presentation if moving forward or backward while not requiring to allocate/create them right from the start.
For such an approach, it's probably necessary to define a "cachingdistance", e.g. having set it to 100 means allocating 50 cards in both directions. This would most probably have the cards available when user starts moving in the GUI avoind the "slow response" in the beginning.

Doing all this would mean:
- building facadelist without any allocations: done with your patch
- visible cards: to be allocated when rendering the GUI: done with your patch
- preallocating cards in the background in a defined distance from current position in both directions
- limiting the memory by a max pool with (FIFO) and dropping the ressources with "biggest distance" - maybe in blocks for better performance

Because I really don't know much about the architecture of those parts, I might be wrong with those thoughts or it might conflict in some areas - so most probably it's best if core devs comment on it ;-)

But for sure, the userexperience very much depends on the "feeling" in the presentation...

 

[ajp8164]

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?