Kodi Community Forum

I'm getting reports from users that since the latest update of my skin (intended for nightly builds) performance with regards to loading fanart and especially posters has been bad on the ATV2.

If anything I expected performance to be better because I actually simplified loading of posters and fanart a bit. I am not using diffuse textures anymore for instance, I am re-using textures more, the skin's total filesize is down by a lot and texture compression has been improved.

The bad performance doesn't seem to be tied to a specific viewtype.
Performance on both my work PC and my HTPC has been excellent and non-ATV2 users of my skin seem to have no problem with performance either.

After going through my code I am at loss at what can be causing this. I've compared the CPU load with other skins and it's about the same.

In the latest version of my skin I am now using bordertextures, whereas I wasn't in the previous version. Is there any way this is something the ATV2 could have specific problems with?

I am making pretty extensive use of stringcompares on the folderpath to determine which viewtypes should be available for certain content types, could that have any effect on the ATV2?

Could there be any performance difference between using xpr or xbt compression?

I am at total loss here, any help would be appreciated.

Jeroen Wrote:I am making pretty extensive use of stringcompares on the folderpath to determine which viewtypes should be available for certain content types, could that have any effect on the ATV2?

Sorry for jumping in (not being an experienced "skinner" myself I don't think I qualify to give advice here) but stringcompares comes with a slight penalty. But, it should not affect performance _that_ much.

Are the stringcompares visible conditions or include conditions?

Visible conditions are checked at every screen refresh whereas Include conditions are only checked once when the window is loaded.

Most of them are conditions on the itemlayout actually but I'm guessing they work the same as visible conditions in that regard. I also use visible conditions on the containers, but I'm not using that any more than I used to.

Only way to cut back on the amount of itemlayout conditions that I can think of is to use seperate containers for different content types, but that opens a whole new can of worms.

I tried to use an include condition for a viewtype instead of a visibility condition on the container itself but then I can't seem to select it unfortunately even though I back out of the window.

In your addon.xml it says "<import addon="xbmc.gui" version="2.11"/>" ... you have to change version to "3.00", there's a new version in the latest nightlies, maybe that's the problem. 2.11 can cause display issues, too.

If a view is used across all media types you can split it down to separate includes for VideoLibrary, MusicLibrary, etc as they'll only load when the relevant window is opened.

Also if you have various items with the same visible condition then grouping them into one with the one condition can't do any harm.

It's something I'm always conscious of when coding.

Have you checked fps between skins, in my experience that's what defines performance for skins.

stringcompares in vis conditions (not include conditions) are slow as shit. Do not use them if you can possibly avoid it.

If we need more support for content type, we'll add it - let us know what you need.

Cheers,
Jonathan

@'Black: Cheers, I forgot to bump the version number

@Hitcher: most of the viewtypes are separate for each library. So I'll have a list view for video for instance and have separate layout conditions within that container. Where I can, I'll use conditions based on Container.Content, but sometimes I see no other way than to use stringcompares. But I may be able to optimize it more though. Cheers

@Big_Noid: yes, the framerate doesn't differ much either. But then again, I see no performance issues myself.

@jmarshall: Ok, I'm already working on reducing the usage of stringcompares. Would substrings make any difference whatsoever or is it "just as bad"?

Well, if there was a way I could use for example:

<visible>Container.FolderPath(..)</visible> without it taking the performance toll of using a stringcompare, that would be a major help.

The thing I'm still struggling with the most is setting conditions for add-ons, and I use stringcompares for that a lot.

For instance I have an icon based viewtype which is used for pretty much every type of content through different layout conditions. So when it's listing movies I have a poster based layout, for episodes a 16:9 based layout, etc.
Add-ons use square icons at the top level, so I want to have a layout tailored to those dimensions. I see no other way than to use stringcompares for those layouts, and the visibility conditions for displaying a button to set that viewtype in the left menu, and so on.
I know I can give all content types the same layout and use keep aspectratio, but I guess I'm pretty anal about it all. I really want the viewtype to be totally optimized for the content that is being listed.

So, basically a content type for add-ons is what I'm after most. Imo, having the add-ons specify the content type just doesn't work. They don't provide the same type of metadata that a movie or tvshow would, making the viewtypes (and the infolabels contained within them) not optimally suited.

substrings is even worse its basically multiple string compare

Jeroen Wrote:In the latest version of my skin I am now using bordertextures, whereas I wasn't in the previous version. Is there any way this is something the ATV2 could have specific problems with?

Just wanted to point out so you feel at ease with this decision, using border textures where possible is a really good thing, it can increase performance a lot!

EDIT: I misunderstood how you used it, so scratch my remark It will not increase performance

topfs2 Wrote:using border textures where possible is a really good thing, it can increase performance a lot!

In regards to skinning in general, could you elaborate this a bit? I'm always interested in possible speed improvements. I.e. how it should be used to increase performance?

pecinko Wrote:In regards to skinning in general, could you elaborate this a bit? I'm always interested in possible speed improvements.

Well on some hw (mostly embedded like atv2 and such) you want the textures to be as small as possible, the border tag allows you to have the middle part of your image (if its of same colour) to be a single pixel.

So you can have a border which is properly displayed and the middle part (which gets stretched to fill the size of the control) to be a single pixel.

This means you can have a control which is 600x600 but with the border of 50x50 (all 4 sides) meaning the entire textures needed is 50x50 + 1x1 to render the 600x600 control, this only makes sense to use if the middle of an image is the same colour, which some times it is. So instead of pre-stretching in photoshop you let xbmc do it and you can save a lot of memory and sometimes the GPU can skip to load as much texture data into the texture cache, which may save a lot of unneeded cycles.

jmarshall Wrote:If we need more support for content type, we'll add it - let us know what you need.

IMHO, two things might come handy:

1. ListItem.Description - that would return Plot, Album_Description, ShowPlot .. etc. With default "No description found" fallback label set.

2. Content.ThumbType (Posters, Square, Banners) - which should return type of thumbnail used. Most of the time I don't really care if it's Movies, TVShows or Addon but what kind of thumbnail is being used on the other side. Addons use banners, wide (16x9 or like) or squared thumbs and IMHO, Addon creator should be encouraged to choose one of the proposed thumb types and set it.

If it's returned as empty we could use 16x9 or like format with keep aspect-ratio.

Jeroen Wrote:@Hitcher: most of the viewtypes are separate for each library. So I'll have a list view for video for instance and have separate layout conditions within that container. Where I can, I'll use conditions based on Container.Content, but sometimes I see no other way than to use stringcompares. But I may be able to optimize it more though. Cheers

You don't want to use Container.Content conditions for Includes because they're only checked when the window is loaded (ie VideoLibrary). So if you used Container.Content(episodes) it wouldn't get loaded because when you first load VideoLibrary it will be at the TV Show level.

If you had a view that covered Music, Video, Pictures, etc you could use them based on the main window being visible.

ie