硬件加速一篇文章

I've been asked to look into the hardwareAccelerated attribute in Honeycomb and I've run into the DisplayList class, which has me a bit puzzled. I can't quite see what it buys you that 'pays for' the code involved.

Sure, it's cheaper to replay a DisplayList when (say) a Toast goes away than it is to re-render that part of the View hierarchy. Similarly, when a window is brought to the front (or the window(s) in front of it go away) it's cheaper to replay a DisplayList than it is to re-render the whole View hierarchy. But these don't seem like the sort of operation that happen several times a second, and so don't seem to call for heroic optimization.

The best theory I've come up with so far involves animations: I'd imagine it's much cheaper to apply a transform to a display list than it is to do a full re-render through a transform.

Am I anywhere near right? Or is my cost-benefit analysis just totally flawed?

Dianne Hackborn

要回复，请登录 11-3-12

将帖子翻译为中文  

This is not part of the SDK; you do not use it as an app developer.  It is used to implement some drawing optimizations in the framework.

Also, this has nothing to do with redrawing when a toast changes or other windows on top of it change (in that case the window is not redrawing at all, its current buffer is just being recomposited to the screen), nor when the window is shown after being hidden (in that case the entire surface is recreated and everything needs to be drawn again).

This is used to implement caching of individual views, so that they can be quickly redrawn when being animated in various ways in their window.  For example, an animation that fades a view in or out or other such transitions.

- 显示引用文字 -

- 显示引用文字 -

-- 
You received this message because you are subscribed to the Google Groups "android-platform" group.
To post to this group, send email to android-...@googlegroups.com.
To unsubscribe from this group, send email to android-platfo...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/android-platform?hl=en.

-- 
Dianne Hackborn
Android framework engineer
hac...@android.com

Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails.  All such questions should be posted on public forums, where I and others can see and answer them.

Jon Shemitz

要回复，请登录 11-3-12

将帖子翻译为中文  

Thank you.

Romain Guy

要回复，请登录 11-3-12

将帖子翻译为中文  

Display lists are not used only for animations. On a tablet resolution, we've observed an important increase in the number of Views the view hierarchy has to deal with. If you read the implementation of draw()/dispatchDraw() in Android's UI toolkit, you will see that there is a fair amount of logic that needs to be executed every single time. The idea of using display lists is to optimize away the execution of that logic and record only the final drawing commands required to render each View. This has two major benefits: we need to run less code and we can run native code instead of Dalvik code.

The way display lists are implemented modifies a little bit the way the invalidation/drawing mechanism works. Before Android 3.0, calling invalidate() on a View would force all of its parents all the way to the ViewRoot to redraw (and therefore run a lot of Dalvik code.) With the new model, when a View invalidates, the parents are left untouched: only the code of the invalidated View is executed to re-record the display list. This means that when you modify a View, we still have to draw all the views that intersect its bounds, but we can do so by running pure native code.

Display lists have another added benefit. When you animate a complex View, for instance a ListView, using the new properties (scale, rotate, x/y, translation and alpha) we can leave the View's display list intact and rebuild the parent's display list instead (the parent applies the transformation.) ViewGroups usually have simpler drawing code and rebuilding their display lists can be cheaper.

I don't have the exact numbers readily available, but by switching to the display lists system we've observed performance improvements ranging from 20% to 80%.

On Fri, Mar 11, 2011 at 4:56 PM, Jon Shemitz  <she...@gmail.com> wrote:

- 隐藏引用文字 -

I've been asked to look into the hardwareAccelerated attribute in Honeycomb and I've run into the DisplayList class, which has me a bit puzzled. I can't quite see what it buys you that 'pays for' the code involved.

Sure, it's cheaper to replay a DisplayList when (say) a Toast goes away than it is to re-render that part of the View hierarchy. Similarly, when a window is brought to the front (or the window(s) in front of it go away) it's cheaper to replay a DisplayList than it is to re-render the whole View hierarchy. But these don't seem like the sort of operation that happen several times a second, and so don't seem to call for heroic optimization.

The best theory I've come up with so far involves animations: I'd imagine it's much cheaper to apply a transform to a display list than it is to do a full re-render through a transform.

Am I anywhere near right? Or is my cost-benefit analysis just totally flawed?