<include condition ="ThisMightNeedAttention">

[byron]

Here is my solution for conditionally including 2344 lines of code (one of about 10 different attempts that should all work that all yield the same results)...http://xbmclogs.com/show.php?id=126373

if you're interested...here's the real code: http://xbmclogs.com/show.php?id=126381

It's simple, it uses a boolean condition that is natively in my skin settings, but xbmc is taking resources even though I thought that it should be just "skipping" right over the condition until the condition is met (doesn't seem to be the case at all)...

Before the Code was ever entered into my Home.xml:

And after:

The difference in "FreeMem" is half a mb, and I'm certain that this is with the condition not being true which means that xbmc should just pass right over all the includes and pretend like code doesn't even exist at window rendering...am I wrong in thinking this? I wish I could paint a clearer picture for what I'm trying to explain, but it's all pretty wishy-washy to begin with. I thought about making a ticket, but wanted to know if I was wrong about something etc...if I'm correct it might save a decent amount of ram from skin to skin if there's an issue with conditional includes not working properly.

[aadc]

hey there mate
im currently using similar code on my skin (xtv-lite) but much simpler

for example i use this code for recently added

Code: Select all

<include condition="!Skin.HasSetting(HomepageHideRecentlyAddedMovies)">MovieLatest</include>

i noticed that my code doesnt have

Code: Select all

file="????.xml"

is there any difference in terms of free ram, with or without the file="????.xml" code ?

[byron]

Right, so your code means that if the skin doesn't have the setting to hide recently added movies then this code will be rendered at window open and you will see recently added movies. If you tick the radio button in skin settings to turn the option off the condition is set to false and xbmc will go right past it saving the resources that it takes to run the code (still not sure if that's entirely true, but it should be). I can't figure out why memory is being lost if a condition is false and xbmc jumps over it...just doesn't make sense which is why I started this thread.

i noticed that my code doesnt have

Code: Select all

   file="????.xml"

is there any difference in terms of free ram, with or without the file="????.xml" code ?

It's very likely, but not certain. If you look at the header of your includes.xml file you will more than likely see a list of other files at the top:

Code: Select all

<include file ="Includes_FooBar.xml"/>
etc...

These are all files that are included into memory as soon as xbmc boots because they are drawn from Includes.xml which is taken into memory at boot for faster window loads, common code that is used over and over again, etc. So to answer your question, if you have many files included into your Includes.xml then yes this way of further conditionally including code will save a considerable amount of ram for sure. Basically the files at the top say these files are always in memory so that the code from them can load faster and smoother (which isn't always the case on our platform). If you take the time to find all of the includes from one of the windows in the header and add

Code: Select all

<include condition="Foo" file="Includes_FooBar">Whatever_Include</include>

and then remove the file from the header of Includes.xml it will no longer be in memory at boot, and can only be seen when the conditions are met. So if you have a lot of files being drawn from then yes it'll make a huge difference (no need to use this approach for includes within Includes.xml since it's in memory all the time anyway)...make a backup of your work and play around with it you'll probably be surprised with the performance gain

[Dom DXecutioner]

xbmc will load all available xml includes for the active window into memory, irregardless of condition being met, which is why you see the memory change... furthermore, once the includes has been loaded, xbmc will keep it in memory until the skin is unloaded...

source: http://forum.xbmc.org/showthread.php?tid=114656

more than likely this is the reason for the memory never returning once you go into any library container; most skinners, including myself, use the <include>view_foo</include> from the includes.xml for the views or <include file="foo.xml">view_foo</include>; using the second option, when you initially get to the home screen screen on boot, we have not navigated to any library container and the views include xml is not loaded, thus the memory is higher; however, when you enter any library container, the xml is then loaded using the include and retained in memory, returning to the home screen will now have less memory that we don't get back because the views have now been loaded until the skin is changed or reloaded.

in theory, it would probably help, memory-wise, to add the views to library window (i.e., myvideonav.xml) instead of using the include...

hope that made sense; i have not tested this, but i will when i get a new xbox (my xbox went out).

[byron]

xbmc will load all available xml includes for the active window into memory, irregardless of condition being met, which is why you see the memory change...

I think you're correct, and that explains a lot. I wish there was some way to only make a file be drawn into memory when the condition is met, rather than checking for included files at window render and then taking them before anything else (don't know how it could work any other way though).

in theory, it would probably help, memory-wise, to add the views to library window (i.e., myvideonav.xml) instead of using the include...

No theory necessary, that's exactly what I did with every view in every window and it works just fine...MyVideoNav.xml has 10,826 lines of code though (465kb) Memory is not as big of an issue at that point and stays constant skin wide. I really only have a few includes at all in it, but you can clearly see the trade off between ram and cpu with debug logging in that sort of enviroment.