[CapnBry]

Actually, what I've found is that it is entirely CPU bound; the graphics code is fine. I've worked in rendering optimization professionally for a spell, but after modifying XBMC to expose the standard bottlenecks, I can say none of the standard rendering issues are a problem. Sure there is a slowdown in load time, which is shared equally between includes, pulling values from the XML (parsing is fast, getting the values is not), and constructing the controls, but that is a one time hit. This is all per-frame CPU time.

I've actually threw together a quick skin proflier, that reports a hierarchical list of time spent in visibility check and render time per control. I think this might be useful for helping skinners optimize if you agree. I'll clean it up and present it soon.

But back on topic, after considering some specialized controls to improve performance, I think this can actually be solved in a more general case by improving the visibility check caching and eliminating the rendering of nonvisible objects. I originally jumped to the conclusion that Aeon 1080p was texture thrashing but really that's not the case.

EDIT: I sort of want to apologize for immediately jumping to the conclusions that the speed was GPU bound, sorry for implying that without looking at the numbers.

[jmarshall]

Yup - go for it - it'd be most appreciated - particularly if it can be done with no (or very little) increased overhead - at the group level for instance.

Controls should already not render if not visible, but ofcourse this should be extended to the case where they're transparent as well (and it should be easy to achieve I think, with a simple check for alpha state in DoRender()?)

As for the visibility stuff - we really need to move to a push-based system for this as much stuff as possible. It's silly to be checking for things every frame when they hardly ever (or in some cases never) change. Not everything is done so easily in this fashion, but there's a bunch of stuff would be relatively straight forward to do.

Cheers,
Jonathan

[needtotest]

Is it possible to load the skins into the library? Over time it must be faster to load views from a db than from xml files over and over again? The xml files could be a transport for the skin so that xbmc could update the db accordenly. To my knowlage xml reading is alot slower than db access.

..then we could get a db skin tool which could make it easier to mod the skins.

/needtotest

[jmarshall]

Given that no one has even verified whether the XML load time is an issue, it's a bit premature to suggest possible solutions to it. It's a one-off operation on window load anyway, so it's very unlikely to be a big problem.

Has anyone actually tried the animation tweak that I and Jezz_X suggested? Get some decent testing to identify the problem, then we'll talk solutions

In either case, an SQL database for skins won't help here - they're no good for storing hierarchical data, but I'm sure other options are available should it turn out that it's really a problem.

Cheers,
Jonathan

[ccMatrix]

Is it possible to load the skins into the library? Over time it must be faster to load views from a db than from xml files over and over again? The xml files could be a transport for the skin so that xbmc could update the db accordenly. To my knowlage xml reading is alot slower than db access.

..then we could get a db skin tool which could make it easier to mod the skins.

/needtotest

I doubt that the skin xml files will be loaded over and over again. The structure is most likely loaded into memory once (since it doesn't change). However the structure is evaluated every frame and then rendered - regardless if there are changes or not. Changes here refers to elements changing visibility or moving, fading etc. In a push based approach, an element, that changed and needs to be redrawn would send a signal back and then the frames would be drawn. So if a text scrolls it would initiate redraws while a completely static display with no movement, fades or other changes would simply remain on the current frame. The problem is that there needs to be some way so that the engine knows when to redraw without missing any frames. And this is not as simple since there are many many things that can go on in skins.

[needtotest]

I do not have any issues with the skin performance at the moment. I am also using my newest pc for this but a htpc should not be a "gamer" pc if you ask me so I think optimisations is always in place where possible. I just believe that reading a skin from db than from xml could improve load time from the first screen to all views. But it is difficult to say how much since it has not been tested.

I once read that an app like delicious library had huge speed improvements going from xml to db. So maybe it could be the same for xbmc?

/needtotest

Edit: Also if there was a way to have a skin load time debug in xbmc like the debug info this could be a great help to skinners and developers in general.

[CapnBry]

Given that no one has even verified whether the XML load time is an issue, it's a bit premature to suggest possible solutions to it. It's a one-off operation on window load anyway, so it's very unlikely to be a big problem.

I actually looked at that yesterday too, as I sort of hinted in an earlier post. The loading of the XML is actually lightning fast. For example, MyVideos in Aeon takes 1.6s to load the skin (no textures) of that, less than 100ms is spent actually reading the XML. There's about 300ms of expanding the XML in memory by inserting includes, 450ms of pulling values from the in-memory xml representation into local variables, and 400ms of actually constructing the controls. There would probably be a benefit to changing the middle step to either:

A) Walk the XML using NextSibling and fill values based on the name of the node rather than searching for every possible item every time. That's a two-fold cleanup as you only deal with nodes that are in the xml, as well as removing all the Find(xxx) type calls which are fast but an order of magnitude slower than the simple Next() walking

B) Only pulling values needed based on control type. This is more of a pain in the ass because it makes the code bigger and will duplicate code but would see a benefit of reduced node lookup counts.

But in either case the point is that the XML isn't the problem, so putting it into a DB or something wouldn't give you very much improvement. You'd have to go further to see any benefit, like maybe adding << >> operator on CGUIControl and stream them to disk in a native format.

Back to the skin profiling, I've implemented it to try to stay out of the way was much as possible. It has a keybinding where now you hit the key and it turns on and every control calls back to the profiler to record its Visible and Render time. After 100 frames the profiler turns off and right now it hits a breakpoint and I examine the results in memory. I'm going to make it so it dumps to a file for easy reading.

[CapnBry]

Edit: Also if there was a way to have a skin load time debug in xbmc like the debug info this could be a great help to skinners and developers in general.

Code:

14:39:48 T:2980 M:4095799296   DEBUG: Load MyVideoNav.xml: 1622.07ms

There's that, which gives you the time to load the XML, do the includes, pull the values, and create the controls. The images are loaded after that and take anywhere from 15ms for small images up to about 250ms (C2D E6750 2.66GHz) for a 1080p image.

[The-Boxhead]

Since i've done some skinning and modding in my time isn't it true that XBMC loads/reads the same xml/images each time you change view ?
Because if i change a image or xml i just exit and enter the same view
and it's updated.

Wouldent it be faster to just read all the xml/images one time when the skin is loaded then do not read xml or images any more ? Or would that be
to memory demanding.. Reading 90Mb of images and a few megs of xml into memory shouldent be any problem ?

[needtotest]

OK the xml loading sounds fast - but if the db only took half the time would that not be better? Again we only compare xml load to an idea of what is fast. In 1.6s you can do alot of record searching.

the time you have in the logfile for loading would be nice to have onscreen like the debug info (freemem/fps/cpu) but ofcouse with some split times like you also mentioned.

/needtotest

[The-Boxhead]

I also tried what JM said about animations:

f you want to see if its the animations add this to the skin.xml
<effectslowdown>.1</effectslowdown>
it will effectively make all the animations 10 times faster 1 is the default value fyi

And if the window loads crap loads faster (obviously the animations in the skin will stuffed at that speed) you know thats the cause.

But my Money is on a combination of
huge textures that take too long to load or can't be loaded proper into memory on weaker graphics cards (not nvidias), use of direct image access hacks (for the extra thumbnails) and animation speeds

Dont know if it worked at all cause i could not spot any difference to the animations at all...

EDIT_
i changed all animations times in the skins Includes_Animations.xml but this didn't make any difference either

[needtotest]

it is in the skin.xml allready but with 1 so just change that to .1 and test it by going to settings which will then just swoosh out - or what ever you want to call it.

/needtotest

[The-Boxhead]

needtotest i understod that i needed to change it in the skin.xml to .1 but
for me it doesent have any effect...

EDIT:
Im retarded today, i changed the wrong aeon xml files
okay it does have an effect, but appart from that animations was gone
the skin still doesent feel "snappy" to navigate.

[CapnBry]

Back to the skin profiling, I've implemented it to try to stay out of the way was much as possible. It has a keybinding where now you hit the key and it turns on and every control calls back to the profiler to record its Visible and Render time. After 100 frames the profiler turns off ... it so it dumps to a file for easy reading.

Here's an example output from the Multiplex view in Aeon. It is a little hard to read because controls don't have names unless you give them a description or some text. Let's have a look at part of the output

Code:

<guicontrolprofiler framecount="100" timeunit="ms">
    <control percent="100">
        <rendertime>7977</rendertime>
        <visibltime>145</visibltime>...

So here we see that for 100 frames, we spent 7977ms or 7.977s rendering and 0.145s checking visibility, this is the top level node so its count includes all child controls as well.

Code:

<control type="group" percent="11">
                        <description>MediaMenu</description>
                        <rendertime>898</rendertime>
                        <visibltime>0</visibltime>

Further down we see MediaMenu, which I put a description on so I can find it, 0.898s. So 11% of the time we're drawing this menu that's not visible.

How's this looking?

[jmarshall]

Looks just fine to me as far as the output goes, though visible has an e

If it's not visible, why is it being rendered (CGUIControl:oRender) - or is this just the time taken in the visibility check? For groups, that time is in Render(), which should probably be split off. There was a reason why I did it that way initially, but I have no idea what it was so have no idea if it's any use still (yes, I should have commented it!)

Agreed about the loading - particularly the "only search for stuff this control needs". Not sure if the other way around (i.e. troll the xml tree only rather than troll for all possible) would cause all that much difference - it'd only better if the number of xml nodes is suitably less than the number of nodes checked for. After defaults and includes are taken into account, it could be the other way around (e.g. overriding of tags).

Serialization was something I thought of as well (i.e. serialize the main controlgroup immediately after first load), but there's the issue of conditional includes to take care of there, and there's the disadvantage for skinners of having to do a skin reload to check changes - we require this for include changes anyway though. We could serialize with a list of the conditions used on includes if we have to. 1.6 seconds is certainly something that needs to be cut down.

Cheers,
Jonathan