9-Patch

[tulamide]

What is a 9-Patch?

Before answering the question, let me ask you another: How would you realize a gui like that?

gui.png (17.69 KiB) Viewed 10768 times

It sure aren't scaled bitmaps as we can see sharp, clear edges and smooth gradients. So is it drawn in runtime, using prims or ruby? You know very well that it is not an easy task and will add to the cpu load. So, is it just one large bitmap, containing all elements? But what if you'd want to change something, like the size of one of the elements, or the color?

What if I told you, that it is none of the above? That it is an editable collection of items? That you can control each of them separately? And that you still need to only store a minimum amount of data? What if I told you, that all the elements are created from one simple, small bitmap - the one that you see at the bottom?

What you see there are 9-Patches. The technique behind it is rather simple. A bitmap is sliced into 9 patches of user-defined sizes, and each patch is scaled independantly based on its position in the bitmap. You can have as many 9-Patch-Modules as you like. Feed them all the same source bitmap to get varying sizes or shapes (by changing the patch sizes). Or feed them with different bitmaps. When you save you schematic, you only save the source bitmap(s). And they can be as small as needed to create the effects you want.

The advantages are immense. For example, it is much quicker than drawing in runtime (some refer to it as 'vector drawing', although not the right term). Just a tiny amount of data is stored with the schematic. Still you are as flexible as drawing in runtime.

A simple calculation: The gui above is of size 519x343. If you'd made just one bitmap of the whole gui, you'd store 695 kB. Since the gui is generated from just the small bitmap at the bottom, you now only store 4 kB.

For me it is the most important module for the graphical interface.

Just feed the module with a bitmap, change to the property view and set the margins. Done.

@Nubeat7
If you'd like to make a ruby version, that would be awesome!

[Exo]

Good work tulamide,

Although I'm not convinced that scaling in sections is any better that just scaling the whole thing in one go?

At least from my quick test the results look no better, the scaling algorithm that FS uses is a very high quality one.

Also scaling will use a large amount of memory even though the bitmap is small, if you increase the bitmap(even in sections) by twice the size it will use four times the memory.(if we are doubling the width and height).

You need to bare in mind that scaling is not free memory wise, when a bitmap is scaled to a larger size a completely new bitmap is created every time the source is scaled. This is happening inside the bitmap area primitive, you are passing your source bitmap and because it has to be scaled a new one is created internally.

We do need something like this though, I think the usual approach is to cut the Image into 9 pieces, the corners are placed as is, and then the rest is tiled via a loop. This approach is light on Memory and CPU because there is no scaling going on, which for a high quality algorithm can be pretty expensive both in terms of CPU and Memory. This technique is used in many GUI Frameworks especially mobile ones where high quality scaling is just not an option because of the limited resources of phones.

The 9 piece system is a bit inflexible though and I think less necessary for PCs than phones or tablets. But still could be beneficial to squeeze extra performance from your GUI.

[tulamide]

Although I'm not convinced that scaling in sections is any better that just scaling the whole thing in one go?

Hey Exo,
thank you for your interest and the comments. I'm totally aware of the 'behind-the-scenes'. I was not talking about RAM load. I think this isn't any problem nowadays (btw, if it was programmed professionally, the only permanent memory use will be the main front panel, where everything finally is drawn - everything else will be buffers). I was talking about the amount of data you store within the schematic (which also influences loading time, for example) - and there you save a massive amount.
9-Patch is not about tiling. The corner patches stay untouched, the top- and bottom-center patches are stretched horizontally, the left- and right-center patches are stretched vertically, and only the inner patch is stretched on both axes. And that's why I can't believe what you said about scaling. If you really see no difference between a 9-Patch and just scaling an original, then there's something wrong. Either on your machine or in my module. Did you set the margins? Without margins there is no benefit to standard scaling, that's the nature of a 9-Patch (tiling it by using the margins).
I'm not sure what you mean by inflexible. But a 9-Patch offers possibilities that a bitmap normally doesn't offer, so it at least makes bitmap use a lot more flexible

[Exo]

Although I'm not convinced that scaling in sections is any better that just scaling the whole thing in one go?

Hey Exo,
thank you for your interest and the comments. I'm totally aware of the 'behind-the-scenes'. I was not talking about RAM load. I think this isn't any problem nowadays (btw, if it was programmed professionally, the only permanent memory use will be the main front panel, where everything finally is drawn - everything else will be buffers). I was talking about the amount of data you store within the schematic (which also influences loading time, for example) - and there you save a massive amount.
9-Patch is not about tiling. The corner patches stay untouched, the top- and bottom-center patches are stretched horizontally, the left- and right-center patches are stretched vertically, and only the inner patch is stretched on both axes. And that's why I can't believe what you said about scaling. If you really see no difference between a 9-Patch and just scaling an original, then there's something wrong. Either on your machine or in my module. Did you set the margins? Without margins there is no benefit to standard scaling, that's the nature of a 9-Patch (tiling it by using the margins).
I'm not sure what you mean by inflexible. But a 9-Patch offers possibilities that a bitmap normally doesn't offer, so it at least makes bitmap use a lot more flexible

Sorry I didn't look at the code properly I thought you was scaling all the sections including the corners ( which obviously makes no sense, my bad)

The way I described where the inner pieces are tiled instead of stretched (which is common mobile phones) is inflexible and can look bad when dealing with gradients when the area is a lot bigger than the original.
Your method actually is very flexible and now I understand what you are doing properly is a great solution thanks.

Like I said I did a quick test and didn't notice a difference this must obviously have been a poor test I just grabbed a square image where the benefits of this will only really be seen for rounded corners I guess.

I will have a play with this I am very interested in improving load times at the minute and I am doing pretty well in that regard. So will be interesting to see the savings possible with this method.