[mark007]

Hi guys, just wondering can any developers comment on skin performance in xbmc. I have been using fraps to monitor fps output from xbmc today and trying various skins.

I'm just very concerned that xbmc / my machine is unable to keep a steady 50/60fps while scrolling through various parts of many skins. I say this because its a fairly fast machine, 12gb ram, 1792mb gtx 295, core i7 920 @ 3.7ghz....

I mean even monitoring cpu / gpu usage using task manager, I don't see all that high usage, in fact gpu usage is almost 0% most of the time, although frame rate drops from 50fps (tv set to 50hz usually), down to about 30-35 consistently when scrolling fast through various views in most guis. My question really is, is xbmc taking advantage of the processing power available to it as I honestly don't think it is, or is there some animations that are timed incorrectly perhaps thats causing these slowdowns even though cpu / gpu and disk usage are nowhere near being maxed out.

I mean this PC is pushing out over 60fps constant in massively gpu / cpu / memory intensive graphics applications like gta 4 at maximum settings @ 1920 x 1080 but scrolling through a list of text / posters can bring it to a crawl. I feel theres some way that the xbmc gui can use the power available to it more efficiently and be able to reach a steady 50 / 60fps without dropping on these relatively fast machines... It just takes away from the streamline htpc interface, when xbmc opens and the gui is initializing and it stutters for a few seconds, only to settle down to 50fps steady, to drop again to mid 30'fps when scrolling through movie lists.

Does anyone agree or have any suggestions as to where the skin engine is falling down speed wise?

In Windows 7 64bit trying any of the popular aeon skins released for dharma..

EDIT: One interesting finding.

With xbmc's vsync on, during one transition from the main aeon nox screen, to the movies section, I go from 50fps in the main menu, to 36fps during the transition, back to 50fps after the transition is complete.
With xbmc's vsync set to off, and using a fullscreen window rather than true fullscreen, during the same transition, I go from 100fps in the main menu (is there a limit of 100 set somewhere in xbmc?), to 72fps during the transition, back to 100fps after the transition is complete.

Why this 100fps limit, and could this be the part of the cause of the unnecessary slowdowns with vsync on. If some piece of code is limiting the number of frames output per second, its going to have an impact when vsync is on if it is also left on.

[jmarshall]

The problem is 100% related to:

1. The fact you have to spool textures off disk. (This can be particularly slow on windows compared to other OSes).
2. Inefficient coding in the skin (lots + lots of textures involved, with insane sizes and/or no background loading involved).

It has nothing, zero, nada to do with the 100fps limit when vsync is off.

Cheers,
Jonathan

[The-Boxhead]

And one of the problems for us that do skin coding is that
it's not an easy task to understand how to code a skin so it becomes
efficient. Im thinkin on xbt compressing, background loading of images, optimum texture sizes both in size and H/V, any many many more questions.

I mean there is just no good documentation on these subjects, i mean i know how to get a button scroller going, how to poulate list views etc.

So my guess is that there wont be that much improvements in skin performance since the general idea is "just fidle around untill it works" then we are all happy.
So one guy copys another guys coding which inturn another guy copies.

So unless someone writes up a proper skin coding guidance we are all in the dark, or maybe its just me

[mark007]

Fair enough but with my HDD being able to read over 200mbps (sequentially of course) and windows showing only < 10 Mbps leads me to believe that's not the cause. Also the GUI doesn't block when loading these images so it shouldn't slow the GUI Down that much.

So in the case of this simple animation from main menu to videos in these skins, I know it's a very general question but in that 1 second animation, what is the skin able to do to slow the gui down so much. All I can do is imagine like can I ask are the intervals for fade animations calculated correctly... I just can't believe this is as fast as it can get.

I'll use this one transition fade from main aeon menu to the videos section to test myself what might have the highest impact on fpa that's bringing it from 50 to 30~ for that second.

[topfs2]

I wrote up some points about this during gsoc, while I focused on embedded much of the stuff holds true on any system. http://elinux.org/BeagleBoard/GSoC/2010_...umentation

It is important to note that every layer you add will up the needed fillrate and processing tremendously, which is one of the biggest culprits on embedded.

I do understand that skinners needs to keep layers (as in PSDs) for maintainability, not sure if we could add a way to flag that these layers will not alter individually but only as a group?

Jmarshall, any thoughts on this? A flag on the group with static or something might be valid? would be very doable to render down that group as a fbo, I guess we might be able to add so that the flag is can be adaptable also, much like vbo's in OpenGL, were you have streaming, dynamic and static. the first means they will always change individually and the group is just for logical reasons, the second is that they may change and the last is that it will never(ish) happen?.

[jmarshall]

The GUI does block when loading the images if they're not backgrounded. Plus the GUI does block once background textures are loaded as they need to be uploaded to the GPU.

Fades and other animations won't make any difference whatsoever - it's all down to disk activity pretty much.

Note that another thing that aeon tends to do a lot is use a shitload of skin variables, each of which has to be written out to disk when it changes. Change lots of them during a couple of frames -> lots of expensive disk writes.

Try other skins. Confluence for instance doesn't show any such stuttering on my laptop (OSX).

The-BoxHead: Good skin coding follows the same rules as most coding: The more code you add, the worse it gets. The very best skins have reasonably small amounts of XML code. Start simple and small. Add features only as you really need them. A lot of skins now have way too many features. I include Confluence in this - IMO it has too many views and too many features that most folk don't care about. Consider this when comparing with what others skins have.

Cheers,
Jonathan

[mark007]

Ok thanks for the explanation. So with disk reads being the main cause for slowdowns for me, can xbmc itself do anything to avoid these skin variables disk writes you speak about. Can it handle that any better.

I suppose in essence is there any plans for the next xbmc to have some better way of handling data on disk ie a smarter way to load this data in bulk rather than just on the fly when required that's causing "some skins" to slow down so much. I can't imagine any disk heavy skin ever having any hope of being smooth to navigate without this enhancement. I can create a feature request for this but I'm sure someone already has something similar created already?

[pecinko]

It is important to note that every layer you add will up the needed fillrate and processing tremendously, which is one of the biggest culprits on embedded.

Inspired by your article and recent experiments with antialiasing. How about adding 2 more attributes to skin engine - antialiasing and cropping?

Antialiasing could be done by applying transparency to cover's borders in order to reduce jagged edges and cropping by subtracting that border from covers. AFAICT, if you need to do any of those, you need to supply diffuse masks. This makes sense when you want rounded edges or gradient effect, but when you only want to crop or smoother (I know it's not real antialiasing) cover edges, maybe skin engine could automatically apply/substract transparent borders instead. Makes sense?

[The-Boxhead]

Most skinners learn skinning by using an existing skin like confluence, then
you start changeing that bit by bit until you have created something new.

I guess confluence is not the best skin to use as a base, i know that
basic and JX360 from Jezz is incredible fast on my ION. So Jmarshall keeping code down, options and textures is deffinitly a good idea. Point noted on my part.

However in the long run this does limit the creativity we will see on skins, offcourse the options bit is good, you dont need a thousend options. But for textures im more concerned. What is currently the recomended "max" number of textures that one can use ? Is it possible to load more textures to RAM and keep them there ? I mean if i got 2Gigs of Ram and 512Mb of onboard graphics memory it should me possible to use some of that. 50MB of textures is not much these days.

[mark007]

So can we agree on what might be possible improvements, to perhaps minimize the need for disk reads during gui navigation if that is infact the biggest culprit for sluggish guis?

If so I'll try to summarize the suggestions in one trac ticket. This will have a huge impact on so many users, and allow even those so called "bloated" skins to operate relatively smoothly. I certainly know it'll make my HTPC a whole lot more beautiful to use.

Perhaps skin wise, either xbmc could read in all images contained within that skins folder (probably not good if there are alot) or per xml file as its about to be used, the skin designer could predefine what images are required per xml, or xbmc could first parse the xml file, and work about what images are needed, load them into memory in one go and then display the gui representation of that xml with images already loaded... I'm just saying an xbmc designer could probably make massive improvements... these are just things I am just thinking of with my limited knowledge of how the skins are used.

Memory management wise, perhaps like an app like photoshop, a certain percentage of memory could be set as maximum used, or an actual value in mb could be configured to keep control.. Just checked the disk size of all of the png's associated with the latest aeon 65 skin and theres 65mb of png's. Converted to raw and loaded into memory I'm not sure how much it would be but probably under 500mb? With many performance htpc's with gb's of ram, I'm sure most would be willing to sacrifice at least 500mb to making their skin smooth... I'm not sure what would be the best way to pre-cache stuff like fanart etc but I'm sure someone will have a good idea for things like that.. At least if the functionality is there to load / preload disk data like images, it can be made configurable somehow to keep everyone happy..

[mark007]

OK well I'll add a feature request on trac so to request that xbmc be able to perform caching of disk related data into memory when xbmc loads, aswell as on the fly, ie skin related images at startup and if possible, posters on the fly for more smooth scrolling.

Trac Ticket: http://trac.xbmc.org/ticket/11174

Now we just need someone interested in implementing this

[Kabooka]

I have been using Aeon for a long time and after Dharma FINAL what i realize is that XBMC 10 is the SHIZINT !!

Personally i dont know what LAG you fellas are speaking of but for me XBMC 10 has brought a buttload of speed improvements for Confluence Customized & Aeon 65.

[pecinko]

Have you read previous posts? It's about posible further skin speed improvements on weaker platforms.

[mark007]

In my case I have a core i7 920 @ 3.8ghz, 120mbps hdd reads and a GTX 295 gpu and can't get full 50 / 60fps frame rates in many skins transitions.

So I think skin speed improvements where jmarshall suggested (minimizing / eliminating the unnecessary disk read / writes by caching data perhaps) should also have a large effect on fairly high performance machines which I would consider this sytem I'm testing on to be.

Try using fraps and see can you get a consistent butter smooth frame rate in your preferred skin while transitioning around it. Transitioning from a movie to the information dialog for that movie for example always drops my frame rate from 50, to 37, to return back to 50 after the transition. My goal would be to see no frame drop at all and have 50 throughout my entire skin browsing experience. I'm sure its possible even without skin developers having to remove any "bloat" from their skins. To me its not the bloat slowing me down, its the fact that xbmc isn't using my machines resources correctly to achieve the best outcome performance wise.

[steppedup]

If you enable DDS, you'll see a HUGE improvement in any skin's responsiveness:

advancedsettings.xml:
<useddsfanart>true</useddsfanart>

There's a few threads out there that go into detail about why using .dds files results in the performance improvement you'll see once you convert to those files.