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

Guzzi

Retired Team Member
  • Premium Supporter
  • August 20, 2007
    2,161
    747
    Country flag
    • Thread starter
    • Moderator
    • #1
    MediaPortal Version: 1.2 alpha svn
    MediaPortal Skin: Black Glass
    Windows Version: WinXP SP3
    CPU Type: AMD X2 3,8 GHz
    HDD: WD 300 GB
    Memory: 2 GB
    Motherboard: Gigabyte 780M
    Video Card: ATI 4550
    Video Card Driver: Catalyst 09-2010
    Sound Card: Onboard (Realtek)
    Sound Card AC3: HDMI out & SPDIF Out
    Sound Card Driver:
    1. TV Card: FireDTV-S2
    1. TV Card Type: DVB-S
    1. TV Card Driver:
    2. TV Card: FireDTV-S
    2. TV Card Type: DVB-S
    2. TV Card Driver:
    3. TV Card: Hauppauge Nova TD
    3. TV Card Type: DVB-T
    3. TV Card Driver: 08-2009
    4. TV Card:
    4. TV Card Type:
    4. TV Card Driver:
    MPEG2 Video Codec: SAF5/PDVD/ffdshow
    MPEG2 Audio Codec: ffdshow
    h.264 Video Codec: PDVD
    Satelite/CableTV Provider: Astra 19.2 / DVB-T
    HTPC Case:
    Cooling:
    Power Supply:
    Remote:
    TV: Samsung 46'
    TV - HTPC Connection: HDMI


    Hi, because I didn't find a bugentry yet, I wanted to link to this problem - have already discussed in IRC some time ago.
    Should get a bugentry to not forget about it - seems it only applies to plugins supporting coverflow, as those parts of the code will skip otherwise. reproducible with internal plugins, e.g. myvideo.
    The screenshots point to the code/calls.

    https://forum.team-mediaportal.com/...rmanceprobs-mepo-1-2-svn-facadeloading-89430/


    Thanks,

    Guzzi
     

    catavolt

    Design Group Manager
  • Team MediaPortal
  • August 13, 2007
    12,923
    9,278
    Lanzarote
    Germany Germany
    Country flag
    AW: coverflow severely slows down facadeload

    With latest SVN 26865 I can´t see no delay in any facade, not even in coverflow (at least with my skins). All facades are drawn in an instant.
     

    Guzzi

    Retired Team Member
  • Premium Supporter
  • August 20, 2007
    2,161
    747
    Country flag
    • Thread starter
    • Moderator
    • #3
    AW: coverflow severely slows down facadeload

    With latest SVN 26865 I can´t see no delay in any facade, not even in coverflow (at least with my skins). All facades are drawn in an instant.
    In the given example I was loading 10.000 elements - so talking about a long list - this took 150 seconds (in debug/profiling mode - 50 in plain mode) compared with approx 2 seconds with 1.1.1.
    But if someone has worked on that topic I could retest - some days ago the problem was still there...
     

    jameson_uk

    Retired Team Member
  • Premium Supporter
  • January 27, 2005
    7,258
    2,528
    Birmingham
    United Kingdom United Kingdom
    Country flag
    I take it you are not trying to load 10,000 items in a single view but loading a share that contains 10,000 files?

    If you are running a revision after 26811 try adding
    Code:
    <entry name="fileexistscache">no</entry>
    to the general section of mediaportal.xml and see if this makes a difference
     

    Guzzi

    Retired Team Member
  • Premium Supporter
  • August 20, 2007
    2,161
    747
    Country flag
    • Thread starter
    • Moderator
    • #5
    AW: coverflow severely slows down facadeload

    Hi jameson_uk,

    what I do is:
    foreach (dbitem-blabla)
    {
    item = new GUIListItem();
    ... (setting properties...)
    item.ThumbnailImage = conf.FileImage;
    item.IconImage = strThumb;
    item.ItemId = number;
    item.OnItemSelected += new MediaPortal.GUI.Library.GUIListItem.ItemSelectedHandler(item_OnItemSelected);

    and then a

    facadeView.Add(item);
    }


    This is done for 10.000 items.

    But to make it independant from "my" code - you have the same, if using e.g. myvideos and choose actors view, that easily brings you several thousand items to add.

    Problem is, that the facadeView.Add() takes exporbitand more time at the new parts for coverflow (_viewCoverFlow.Add(item)) - almost 150 seconds... in addition...

    the whole process of adding 10.000 items without the coverflow in MePo 1.1.1 took only approx 2 seconds ...

    Anyway, will quickly compile the latest SVN and try use the setting you mentioned above (I assume it's disabling the new caching?)

    Will post results....
    Thanks, Guzzi
     

    Guzzi

    Retired Team Member
  • Premium Supporter
  • August 20, 2007
    2,161
    747
    Country flag
    • Thread starter
    • Moderator
    • #6
    AW: coverflow severely slows down facadeload

    ok, I tried with svn version 26907 and the above mentioned setting, but it didn't really improve performance - still taking approx 60 seconds (nondebug version), so about the same as before.
    Unfortunately I cannot do any profiling anymore, because I used the ANT profiler evaluation version, that is now expired ....
    But I have attached the picture I have taken some weeks ago, that show imho the "problem" -
    The public void Add(GuiListItem item) {} takes for >10.000 counts (see "Hit Counts") for all viewmodes only a few milliseconds - but for the CoverFlow 150 seconds.
    Is there a possibility to disable the coverflow, so this _viewCoverFlow.Add(item) will not be called ? (where and when is bool _viewCoverFlow set?)

    1-2svn-GUIFacadeControl-Add.JPG

    PS: I should mention, that I use a SSD - so the caching really doestn't help so much, because filesystem allows approx 50.000 i/o's per seconds also without caching .... but seems anyway, it's not really a problem of the caching dictionaly ... ?
     

    Guzzi

    Retired Team Member
  • Premium Supporter
  • August 20, 2007
    2,161
    747
    Country flag
    • Thread starter
    • Moderator
    • #7
    AW: coverflow severely slows down facadeload

    ok, I tried with svn version 26907 and the above mentioned setting, but it didn't really improve performance - still taking approx 60 seconds (nondebug version), so about the same as before.
    Unfortunately I cannot do any profiling anymore, because I used the ANT profiler evaluation version, that is now expired ....
    But I have attached the picture I have taken some weeks ago, that show imho the "problem" -
    The public void Add(GuiListItem item) {} takes for >10.000 counts (see "Hit Counts") for all viewmodes only a few milliseconds - but for the CoverFlow 150 seconds.
    Is there a possibility to disable the coverflow, so this _viewCoverFlow.Add(item) will not be called ? (where and when is bool _viewCoverFlow set?)

    View attachment 72736

    PS: I should mention, that I use a SSD - so the caching really doestn't help so much, because filesystem allows approx 50.000 i/o's per seconds also without caching .... but seems anyway, it's not really a problem of the caching dictionaly ... ?
    ok, made some more tests and looked in the code to find, where _viewCoverFlow is set - it's done when reading the XML Skinfile and only if there is a control existant that defines the properties and subitems for the coverflowview - so I removed this part from the skinfile and after that, facadeload is as fast as in 1.1.1 before - regardless of enabling or disabling the setting
    "<entry name="fileexistscache">no</entry>"
    (probably no difference because of SSD, as mentioned above).

    So I think a solution should be in the context, how coverflow initializes when adding an item to the facadelist - either change it to the same way as for filmstrip (which is fast - probably does imageloading later at rendertime for visible elements, but didn't check in detail) or - if it's required to preload all the cardstuff (AddCard, OnCard, etc.) in advance (to have it available at rendertime) maybe doing this loading asynchronous/threaded for not blocking the GUI with that?

    The delay also occurs, of currentView is e.g. listview - because the "_viewCoverFlow.Add(item)" call will be done regardless of the currentview and only dependant, if the view is defined in the skinfile. But I think a solution to only load it if the currentView is coverflow is not a good solution, because then still adding items would be slow in case the user has set coverflow ...

    btw., I should also mention, that the current implementation has a big memoryconsumption with _viewCoverFlow true when loading lots of items - this also disappeared after disabling coverflow in the skinfile ...
     

    jameson_uk

    Retired Team Member
  • Premium Supporter
  • January 27, 2005
    7,258
    2,528
    Birmingham
    United Kingdom United Kingdom
    Country flag
    So you are saying that if a coverflow control exists in skin for a facade and you load a list that the loading of the list is slower?

    Having had a quick look I can only see that cover flow is slower when using cover flow not just because it is enabled.

    I am slightly confused as what you are trying to achieve. you don't need to access the_viewcoverflow directly. You can just use facadeview.add

    As regards memory usagee, cover flow is not really designed (or usable) with 10,000 items anyway. Even if you have images of 128Kb each this is still 1.22Gb worth of thumbs.
     

    SilentException

    Retired Team Member
  • Premium Supporter
  • October 27, 2008
    2,617
    1,130
    Rijeka, Croatia
    Croatia Croatia
    Country flag
    I think the point is here, as soon as coverflow is defined in the skin facade. facadelayout.Add() method takes considerately more time than without coverflow. And even with the same number of items, other layouts work and fill fine. So this is definably something to look at and fix.
     

    Guzzi

    Retired Team Member
  • Premium Supporter
  • August 20, 2007
    2,161
    747
    Country flag
    • Thread starter
    • Moderator
    • #10
    AW: Re: coverflow severely slows down facadeload

    So you are saying that if a coverflow control exists in skin for a facade and you load a list that the loading of the list is slower?

    Having had a quick look I can only see that cover flow is slower when using cover flow not just because it is enabled.

    I am slightly confused as what you are trying to achieve. you don't need to access the_viewcoverflow directly. You can just use facadeview.add

    As regards memory usagee, cover flow is not really designed (or usable) with 10,000 items anyway. Even if you have images of 128Kb each this is still 1.22Gb worth of thumbs.
    yes - in GUIControlFactory/Create there is after reading the elements of the skin:

    if (subControl is GUICoverFlow)
    {
    facade.CoverFlowLayout = subControl as GUICoverFlow;
    }

    so if coverflow-definitions exist in skinfile:

    <control>
    <description>Cover Flow view</description>
    <type>coverflow</type>
    ...

    facade.CoverFlowLayout won't ne NULL anymore - and thus triggering all following actions in the code - including the earlier mentioned call when adding an item.
    Maybe I was unclear, I am NOT chaning anything in the code - just removed the control of type "coverflow" from the skinfile.

    And yes, of course I am using the "facadeLayout.Add(item)" - I was jumping in MePo code to try understand and find the reason for the delays - that's how I found the way "back to the skinfile", that makes the delay disappear.
    10.000 items just makes it ewasier to see the differences - and the fact, that the .Add(item) takes several 100 times longer than without - and all other views seem to work fine with 10.000 items and loading in just a second... plus the memoryproblem seems not to appear in e.g. filmstrip.

    I think the point is here, as soon as coverflow is defined in the skin facade. facadelayout.Add() method takes considerately more time than without coverflow. And even with the same number of items, other layouts work and fill fine. So this is definably something to look at and fix.
    Exactly -and even if you limit to let's say 1000 items (which is something that is realistic) you compare some milliseconds with coverflow off to more than 10 seconds with coverflow activated in the skinfile...
     

    Users Who Are Viewing This Thread (Users: 0, Guests: 1)

    Top Bottom