skin performance on ATV2

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

Hitcher Wrote: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

PHP Code:

<include condition="IsVisible(VideoLibrary)">Video_Layout</include>
<include condition="IsVisible(MusicLibrary)">Music_Layout</include>
<include condition="IsVisible(Pictures)">Pictures_Layout</include>
<include condition="!IsVisible(VideoLibrary) + !IsVisible(MusicLibrary) + !IsVisible(Pictures)">Default_Layout</include> 


I have been trying it out and I really like this, and through grouping by content type within the itemlayout as well this would allow me to reduce the amount of code a lot, but there's one big downside to this for me.

I want the itemlayout to have a different height when I'm either at the videolibrary root or the content node's root (so where you pick genre, year, etc). I've been pulling my hair out, but I doubt if there's a way to do that?

This returns empty when in the root -

I can easily add Content(Root) or some more appropriate flag - note that there is more than just "root" here - eg with flatten off you also just get a bunch of nodes listed, which I suspect you'll want to use the same view type for.

I cannot (currently) add things for differing thumb sizes, and indeed, assuming that a particular content type corresponds with a particular thumb size is incorrect (though I suspect it's close enough that you need not worry about it).

Instead, you should use aspect keep with the thumb centered within the box where appropriate. That way, it will work well for those thumbs that are the size you are assuming, but will also ensure that those thumbs that aren't the size you are assuming don't get stretched incorrectly.

Cheers,
Jonathan

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

Jezz_X Wrote:substrings is even worse its basically multiple string compare

More interesting info for me to digest.

Does adding 'Left' or 'Right' make any difference to a SubString control?

Hitcher Wrote:This returns empty when in the root -

I know, I was aiming more for a check in the including stage, but I realize it's not possible as it's only executed when the window loads.
I got around it by using the including method you posted, and then having two separate layouts with a visibility condition to check if I'm at the root. So, I'm still using a visibility condition, but at least I'm using it less.
I found some more ways to avoid them and the amount of code for my list view for example is less than 50% of what it was before

jmarshall Wrote:I can easily add Content(Root) or some more appropriate flag - note that there is more than just "root" here - eg with flatten off you also just get a bunch of nodes listed, which I suspect you'll want to use the same view type for.

Yeah I was thinking about that later too. Right now I'm using ![Container.Content(movies) | Container.Content(tvshows),etc] to separate those from the higher level nodes. So I guess I would still need to do that if Content(Root) was available.
If Content(Root) would apply to the files node too, it would be a good substitute for using stringcompare(Container.folderpath,sources://video/) though.
Let me think about it as I work on this, I wouldn't want you to spend time on it if there's not enough need for it.

edit:

One that I could definitely use would be a substitute for
stringcompare(Container.FolderPath,special://videoplaylists/)