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 ...[...] it also forces those 2 animations to allocate resource (load textures) as soon as each item gets added [...]
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!!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.
This strategy sounds good to me - and it should imho also be taken into consideration for FS, as it imho improves userexperienceWhile 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).
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.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.
|A||UK - BBC2 EPG suddenly has several programs daily with 'No information'||Electronic Program Guide||57|
|T||Client / Server slow channel-to-channel change (zapping)||General Support||1|
|C||Importer works super slow||My TVSeries||5|
|1.23.0 Slow rendering times||Bugreports||46|
|A||Client/Server Setup: Slow TV Startup||Television (MyTV frontend and TV-Server)||0|
|F||GUI incredibly slow Performance||General||22|
|P||Very slow start||My TVSeries||2|
|seek video over lan very slow for big and highbitrates videos||General Support||11|