custom views and hardware acceleration in android

Who?

Shameless plug by Royi Benyossef (+royiby).

Royi benyossef.

● Android developer since 2008.● Android group leader at Vidmind.● Android speaker and lecturer.● Android Mentor at CampusTLV. ● Android GDE 2013, 2014.● GDG Herzeliya co-founder.

Learn to accel*(erate).

(.by Royi Benyossef (+royiby

.the guide to HW accel

* I know that’s not how you write excel :P

Learn to accel(erate) by Royi Benyossef (+royiby).

Motivation

what do we want?!

Motivation


● Better looking UI.

● Smoother animations.

● Smaller mem. footprint.

● Smaller CPU load.


prolog - HW accel.

HOW?

Hardware

accelera

tion


prolog - HW accel.

What i

s that?

Definition


Use the GPU:

● separate HW component

● Specific design (non-generic).

● separate resources.

● separate SW pipe impl.

In Android


What does it do (when enabled)?

● canvas Drawing is done by the GPU in the

HW based drawing model rather than the

SW drawing model.

SW drawing model


What happens?

1. Invalidate hierarchy.

2. Draw hierarchy.

HW drawing model


What happens?

1. Invalidate hierarchy.

2. Record & update display lists.

3. Draw hierarchy.

Are you kidding me?!


Not sure if stupid...

Or didn’t make his point yet...

The point #1 part 1


In the SW model, when invalidate() is called:

1. the calling item is redrawn.

2. Any affiliated view to the item is redrawn.

http://developer.android.com/reference/android/view/View.html#invalidate()

The point #1 part 2.


Impacts:

1. Non-invalidated views are refreshed (for

better or worse).

2. A lot of drawings all the time.

3. Command done immediately.

The point #2 part 1


In the HW model, when invalidate() is called:

1. the calling item’s drawing is saved to the

display list.

2. The display list is updated.

3. Draw diff.

http://developer.android.com/reference/android/view/View.html#invalidate()

The point #2 part 2.


Impacts:

1. Non-invalidated views are NOT refreshed.

2. Command is done on the HW sync signal.


Yay!

Accelera

te all t

he

thin

gs!!!


Not yet.

by API level


Availability & default status:

● API < 11 - Not

available.

● API >= 11 (HC 3.x) - Available, off.

● API >= 14 (ICS 4.x) - Available, on.


Wait….

There’s a disable

API!


Disable? why?

If it’

s so

good?

Why is

n’t it

always

on?

Default? why?


Why not always on?

● Increased RAM usage.

● Not all operations are supported (API level

dependant).

● Sick strange things.

When is it safe?


When do i have nothing to worry about?

● using only standard views.

● Min API level >= 17.

Worst case scenario?


What might happen?

● Invisible UI elements.

● Exceptions.

● Badly rendered pixels.

scenario example #1


scenario example #2



Wait….

What if that means no more custom views?!?!


Don’t push it.

So…?What to do?

Check!

● Open the list: http://developer.android.com/guide/topics/graphics/hardware-accel.html#drawing-supp

ort

.

● Check.


http://developer.android.com/guide/topics/graphics/hardware-accel.html#drawing-support

http://developer.android.com/guide/topics/graphics/hardware-accel.html#drawing-support

Test #1

● On as many devices as possible.

● HW accel. turned on.

* Device library - http://www.campustelaviv.com/hackspace/


http://www.campustelaviv.com/hackspace/

Test #2

● Systrace.

● tracer.

● GLtrace.

* Here’s Ran Nachmany’s great session on that:

https://www.youtube.com/watch?v=aEFxqdPgHJk


https://www.youtube.com/watch?v=aEFxqdPgHJk

And...


If bugs w

ere

found...

Tips, tricks and patterns


Getting st

arted!

design & impl. correctly

Reduce the number of views.

Less views means smaller display lists and less to draw (for HW and

SW drawing models).



Avoid overdraw.

● Rule of thumb - never draw more than X2.5 of the number of

available pixels.

● Merge/remove layers when you fail at #1.

● Transparent pixels in bitmaps count!



New is bad!

● Never create new Objects in the rendering functions (common

mistakes including new Path or Paint objects).

● Doing #1 causes the garbage collector to run a lot (a very

expensive action).



Beware of modifications.

● Shapes/circles/paths create new texture masks whenever

they’re changed.

● Bitmaps are reloaded to the GPU whenever they’re altered.



Alpha belongs w/ HW accel.

● Alpha manipulations are created in an off-screen buffer which

should be dealt in a hardware layer type.



go easy on GPU loading.

private class PieView extends View {

public PieView(Context context) {

super(context);

if (!isInEditMode()) {

setLayerType(View.LAYER_TYPE_HARDWARE, null);

}

}

...

}


HW accel. control

Control is allowed in the following resolutions:

● Application.

● Activity.

● Window.

● View & layer.


HW accel. control

● Application:

<application android:hardwareAccelerated="true" ...>


HW accel. control

● Activity:

<application android:hardwareAccelerated="true">

<activity ... />

<activity android:hardwareAccelerated="false" />

</application>


HW accel. control

● Window:

getWindow().setFlags(

WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED,

WindowManager.LayoutParams.FLAG_HARDWARE_ACCELERATED

);

Note: You currently cannot disable hardware acceleration at the window

level.


HW accel. control

● View & layer:myView.setLayerType(View.LAYER_TYPE_SOFTWARE, null);

Note: You currently cannot enable hardware acceleration at the view level. View

layers have other functions besides disabling hardware acceleration. See

View layers for more information about their uses.


http://developer.android.com/guide/topics/graphics/hardware-accel.html#layers

accel. control: layers

LAYER_TYPE_NONE - not backed by any off screen buffer, rendered

in the SW model.


http://developer.android.com/reference/android/view/View.html#LAYER_TYPE_NONE


LAYER_TYPE_HARDWARE - if HW accel. is on, layer is backed by HW

texture buffer and rendered in the HW model, else it is the same as in

the case of LAYER_TYPE_SOFTWARE.

*Best suited for performance:

● drawing can be delayed until invalidate is called.

● Some animations such as alpha animations can be added directly

to the HW texture without redrawing,


http://developer.android.com/reference/android/view/View.html#LAYER_TYPE_HARDWARE

http://developer.android.com/reference/android/view/View.html#LAYER_TYPE_SOFTWARE


LAYER_TYPE_SOFTWARE - backed by a Bitmap as if it was a buffer,

rendered in the SW model.

*Best suited for compatibility:

● API - if your min API is less than 11.

● hardware - some GPUs excel in different kinds of animations and

have poor performance in other kinds of animations.


http://developer.android.com/reference/android/view/View.html#LAYER_TYPE_SOFTWARE

accel. control: getters

How do you determine dynamically whether a view is HW accelerated:

● View.isHardwareAccelerated()

● Canvas.isHardwareAccelerated()

Prefer Canvas.isHardwareAccelerated() especially within the drawing

code since a view attached to a hardware accel. window can still be

drawn in the SW model (like when it’s drawn to a bitmap for caching).


http://developer.android.com/reference/android/view/View.html#isHardwareAccelerated()

http://developer.android.com/reference/android/graphics/Canvas.html#isHardwareAccelerated()

http://developer.android.com/reference/android/graphics/Canvas.html#isHardwareAccelerated()

● HW accel. - good but not all the time.● GPUs - have strong and weak points; make

sure you use the strong points and avoid the weak ones (dah!).

● Less is more - create only what you need and when you need it and avoid new instances whenever possible.

● Analyze and adapt - your custom views at all times.

Key points


“We Should Be Building Great Things. Things That Don’t yet Exist”

I hope you liked it.

by Royi Benyossef

Thank you for listening

custom views and hardware acceleration in android

Technology

erateby royi benyossef

hw model

hw drawing model

prolog hw accel

w hw accel

design impl

sw model

sw drawing models