[`Black]

The texture managers store a single instance of each texture. Those textures are then shared between controls. Thus, the loading is only ever done once - it's essentially free to use the same texture multiple times on the same window (other than render + setup costs). So icon and it's reflection is a single load (though you're typically diffusing the reflection, so if the diffuse isn't loaded it's 2 anyway).

How is it done with the same texture in multiple windows, e.g. when I use a large background texture in all windows as an overlay? Is that texture also loaded only once?

[jmarshall]

Now back slightly from this discussion to a question about what is better coding wise for defining textures in controls. If I have a texture in a control that I don't want shown, what is the better way (in terms of efficiency) to code this. For example
Do I drop <texturenofocus> completely, code it as <texturenofocus></texturenofocus> or continue to code it as <texturenofocus>-</texturenofocus> ?

The second two are identical - i.e. "-" is interpreted as empty. The first will also be the same, as long as you haven't also defined <texturenofocus> in defaults.xml. So basically all these are exactly the same. I guess one could argue that the first would be marginally more efficient as it's less XML to parse, but we're talking picoseconds during a load of microseconds

How is it done with the same texture in multiple windows, e.g. when I use a large background texture in all windows as an overlay? Is that texture also loaded only once?

It depends . Typically if it's a large background texture, then the same texture will be used, assuming it was used within the last 2 seconds in the previous window. This is because the large textures hang around for 2 seconds before they're removed, exactly for this (as well as moving quickly between two items with separate fanart images etc.) If it's a texture in the XBT, then it's not necessarily so clear. I *think* that the same thing will happen, as long as it's used in the previous frame in the previous window.

As for the corner texture thing, I guess my point is that "round" is the current fashion. But round might mean different things to different people - it might also include some sort of edge highlight, or be slightly more oval than round, or angled, or you might want to put glass over the top etc. Thus, allowing it to be specified using a texture allows the flexibility for the skinner at just a tiny bit of extra effort. Further, it easily allows you to see what it will look like as you're mocking it up in Photoshop/Gimp etc. Basically you want a "bordered diffuse" where the border applies to the diffuse rather than the texture. I'm not sure the best way to incorporate that within the current XML element. Perhaps we need to just bite the bullet and allow separate bordering on diffuse (via diffuseborder) texture anyway by basically splitting up the model (rendering 25 quads instead of 9 if it's put on both required).

Cheers,
Jonathan

[Hitcher]

How is it done with the same texture in multiple windows, e.g. when I use a large background texture in all windows as an overlay? Is that texture also loaded only once?

It depends . Typically if it's a large background texture, then the same texture will be used, assuming it was used within the last 2 seconds in the previous window. This is because the large textures hang around for 2 seconds before they're removed, exactly for this (as well as moving quickly between two items with separate fanart images etc.) If it's a texture in the XBT, then it's not necessarily so clear. I *think* that the same thing will happen, as long as it's used in the previous frame in the previous window.

It's also worth using <backgroundcolor>0</backgroundcolor> so the window doesn't get cleared if you're using a background texture for all windows.

[wyrm]

Now back slightly from this discussion to a question about what is better coding wise for defining textures in controls. If I have a texture in a control that I don't want shown, what is the better way (in terms of efficiency) to code this. For example
Do I drop <texturenofocus> completely, code it as <texturenofocus></texturenofocus> or continue to code it as <texturenofocus>-</texturenofocus> ?

The second two are identical - i.e. "-" is interpreted as empty. The first will also be the same, as long as you haven't also defined <texturenofocus> in defaults.xml. So basically all these are exactly the same. I guess one could argue that the first would be marginally more efficient as it's less XML to parse, but we're talking picoseconds during a load of microseconds

Cheers,
Jonathan

Jonathan,

I have been applying a number of these suggestions to my skin, and yes you are right it has pretty well got down to picoseconds difference now (in other words pointless). Still the thread has proved useful in a number of areas. Hitchers point about <backgroundcolor>0</backgroundcolor> is also another useful (and worthwhile optimisation)

Thanks for the tips
Wyrm (xTV-SAF)

[pecinko]

As for the corner texture thing, I guess my point is that "round" is the current fashion. But round might mean different things to different people - it might also include some sort of edge highlight, or be slightly more oval than round, or angled, or you might want to put glass over the top etc. Thus, allowing it to be specified using a texture allows the flexibility for the skinner at just a tiny bit of extra effort. Further, it easily allows you to see what it will look like as you're mocking it up in Photoshop/Gimp etc.

Just for a sake we understand each other - when I said "built-in rounding would be enough if you are not into some special effects, I had in mind keeping things as they are and only adding additional possibility so one could use:

PHP Code:

<texture background="true" diffuse="showcase/PosterMask.png">$INFO[ListItem.Icon]</texture>
    <aspectratio scalediffuse="false">scale</aspectratio>
<roundcorners corner="8">true</roundcorners> 


Basically you want a "bordered diffuse" where the border applies to the diffuse rather than the texture. I'm not sure the best way to incorporate that within the current XML element. Perhaps we need to just bite the bullet and allow separate bordering on diffuse (via diffuseborder) texture anyway by basically splitting up the model (rendering 25 quads instead of 9 if it's put on both required).

I'm afraid that we won't be able to keep rounded corners intact and allow diffuse resizing. I will try to do some tests over the weekend but I think we would run into problems with aspectratio=keep. I may be overlooking something but as I see it you can start with diffuse that has 1:1 aspect ration and enlarge it to AR 3:1 or 1:3 using left/right or top/bottom borders. What happens when thumb is 4:3? You would need to use 4-side border and this would work nicely only if corners are sharp.

Maybe your quads example is taking care of this, will try to google some about it.

[`Black]

I have a question about animations. Let's say I have a rotating loading indicator like this:

PHP Code:

<control type="group">
    <visible>some_condition</visible>
    <control type="image">
        [...]
        <animation effect="rotate" center="auto" start="360" end="0" time="1500" loop="true" condition="true">Conditional</animation>
    </control>
</control> 


Does the animation carry on if the group is hidden? If so, would this be the proper solution or is it not necessary?

PHP Code:

<control type="group" id="1">
    <visible>some_condition</visible>
    <control type="image">
        [...]
        <animation effect="rotate" center="auto" start="360" end="0" time="1500" loop="true" condition="Control.IsVisible(1)">Conditional</animation>
    </control>
</control> 


[jmarshall]

If a group is hidden then it isn't processed, thus nothing inside it is processed. So the animation will not carry on.

[Dom DXecutioner]

If a group is hidden then it isn't processed, thus nothing inside it is processed. So the animation will not carry on.

Apologies for asking; however, had this always been the case? That is to say, does this also apply to the original Xbox GUI engine?