Why is setColor so slow on Android

Question

I'm benchmarking some of our code on an OPO device that's normally pretty fast and I'm seeing a lot of "weird" performance oddities. Before digging deeper into the Android native code I thought I'd ask here.

What I'm seeing is that a call for paint.setColor(argbInt) takes roughly 5 times longer to execute than the following calls:

paint.setStyle(Paint.Style.FILL);
paint.setAntiAlias(false);
canvas.drawRect(x, y, x + w, y + h, paint);
paint.setAntiAlias(antialias);

Now draw rect happens on the GPU so I'm guessing I don't see any overhead for that. But why should I get overhead for the paint color?

And as a natural followup, how do I reduce said overhead?

I'm also seeing quite a bit of overhead for canvas.restore() (roughly 4 times slower than the code above) but I guess that would make sense as it could be a complex operation. I just don't see why setColor would be slow?

For the record I tested the performance on an OPO with System.nanoTime() and its pretty consistent in terms of performance (not a sudden GC fluke or something).

Jumper

I guess that setColor triggers some events which take time. If there is any custom artwork in your paint and/or its sub-components, then the display should be re-calculated. I repeat: I guess, since I am not an Android developer :) – Workman

Have you tried creating Color instance to apply? – Capello

'cause probably in setColor the CPU loops over all the pixels of paint, while the others it sets some variable and the GPU does the rest of the heavy work – Aquiver

I haven't tried the version that accepts the color since the variable arrives from a rather different location but that would be interesting to save. There is nothing in the paint other than solids so there should be no pixels to loop over. This is effectively a filled rectangle with a solid color. – Jumper

What is an alternative? Is there any faster solution? – Surgeon

I didn't find any reason so I picked a workaround and answered below – Jumper

Answer 1

I could find no real answer for "why" this is happening even after digging thru the code. My solution was to cache Paint objects for every style in our theme so repainting the component with similar settings can reuse a previously set value. This did seem to have a positive impact on performance.

Jumper