What should i use for better performance, nine-patch or drawable xml resource?

Question

What is the best way to set background for some view? For example 2 variants of backround:

1. background with gradient, rounded corners and border
2. background with just one color and rounded corners

So which of variants would be better, nine-patch or drawable xml resource?

Idiotism

I dont't know! :) But since the standard android themes use 9patch alot, i would asume that doing so can't be too wrong. – Fax

I meen if i need just one color background, maybe xml resourse would be faster? At least xml file would be smaller size – Idiotism

if you only need one color, set background with it . no need image resource ,no need xml config – Appointive

but, what if i need rounded corners? – Idiotism

Answer 1

My guess is, NinePatch would be slightly faster in most cases. Here's what I found.

GradientDrawable (the one used for rects in xml) uses this code to call through to Canvas which in turn uses native call leading to SkCanvas, SkDraw and eventually SkScan and SkBlitter.

On the other hand, NinePatch's draw() has almost zero Java code before the native call to NinePatch.cpp which shortly calls NinePatchImpl.cpp -- NinePatch_draw() --- and that's where the magic is. The code there iterates over the marked regions and after a number of subsequent calls draws stuff using roughly the same logic in SkDraw (only drawRect() instead of drawPath()) but in the end it's the same SkScan and SkBlitter that do the work.

All that code is pretty hard to wrap my head around instantly, but what did catch my eye is that GradientDrawable makes two calls to the whole native stack if it has both background and stroke (look here), while in any scenario a NinePatch only makes one.

So, without actually measuring times for both approaches I get a feeling in most cases NinePatch wins the race: if we [awfully] roughly assume that native call stacks for drawRect() and drawPath() use pretty much the same logic and [another awful simplification] the parameter sets that get passed around there and are created by NinePatch and GradientDrawable don't affect complexity of the methods that much, then NinePatch turns out to be roughly 2 times faster than GradientDrawable with filling and outline. Well, provided you use a regular, 9-section 9-Patch (i.e. don't shred you 9-Patch by an awful lot of markers, making the iteration over the pieces overly effort-expensive).

Anyone who'll stumble upon this and knows more on the subject (and/or better at estimating complexity of native code), please, correct me if I'm wrong.

PS yeah, I know this is not much of a straight answer

Breeches

Great job, thanks for your answer. It's almost what i wanted to hear. You showed to me a good example to look deeper in source :) – Idiotism

Actually, I'm editing the answer right now, turns out I overlooked some stuff, so I'm removing some of the argumentation :) But afaik the outcome is the same - NinePatches win. – Breeches

+1. In simplest words : ready made pixel data versus procedurally generated one with extra CPU cycles. This is true in general computer graphics as well. – Southwestward