Appearance manager

[dottore]

tipstir is right, every png "steels" a bit of performance (although tipstirs skins use images for buttons too ;-).

a set of composite images would be cool. for example, let's have a buttons.xml in the appearance-folder, where we define buttons like this:

<compositeImage "whiteButtonNormal" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>

<compositeImage "whiteButtonSelected" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>
<compositeImage "BlackButtonNormal" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>

<compositeImage "BlackButtonSelected" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>

then appearance manager could display "whiteButton" and "BlackButton". if the user selects one, the manager could overwrite the buttons in baseskin.xml.

just an idea.

[Old Dog]

tipstir is right, every png "steels" a bit of performance (although tipstirs skins use images for buttons too ;-).

a set of composite images would be cool. for example, let's have a buttons.xml in the appearance-folder, where we define buttons like this:

<compositeImage "whiteButtonNormal" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>

<compositeImage "whiteButtonSelected" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>
<compositeImage "BlackButtonNormal" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>

<compositeImage "BlackButtonSelected" size="x,x">
<drawRect....
<drawImage.....
whatever
</compositeImage>

then appearance manager could display "whiteButton" and "BlackButton". if the user selects one, the manager could overwrite the buttons in baseskin.xml.

just an idea.

This is an interesting idea...

[Old Dog]

There could be multiple xml files representing coordinated elements, not just buttons, but headers, selection bars, etc.

The AM would display the Main Menu button from the set and when selected the whole file is copied into the baseskin.xml.

[dottore]

even better.

[Old Dog]

Not sure GBPVR provides the functionality for this yet.

We need to think about this a while...

[Old Dog]

If CompositeImages could be nested, it would work.

[Old Dog]

BTW, the current approach does allow for sets of coordinated elements.

[Old Dog]

Is there AN AUTHORITY that could comment on the MVP performance hit of drawing .png images for buttons vs inline coding?

[KingArgyle]

Not sure...sub should be coming out with some best practices for skinning, but from my understanding. GBPVR just builds the graphic image and then sends the combined image to the MVP. So....don't know if there is any slow down between combing a already made image and one that is drawn by GBPVR itself. I think it has more to do with the size of the images than how they are put together.

[sub]

Not sure...sub should be coming out with some best practices for skinning, but from my understanding.

Dont worry, I havnt forgotten about this. Its more about best practices for developers writing plugins etc, but does cover some of the related skinning aspects. I made a really good start on it over the christmas break, but I've been very busy with work since then. Hopefully I'll finish it off some time soon.

Is there AN AUTHORITY that could comment on the MVP performance hit of drawing .png images for buttons vs inline coding?

Its not necessarily true for all composite images, but when it comes to buttons, there should be virtually no difference. All the composite images used for buttons are only every drawn once, then the resulting button images (both normal and selected) are cached as a bitmap for quick acess whenever they needed in the future. This is true regardless of what your composite image is made up from.