使用位图高效onDraw，硬件加速复杂剪辑

Question

I'm looking for advice about optimal rendering (and possibly caching) of animated content whose nature is determined at run-time and cannot be pre-computed.

I am developing my first Android app, and have decided on a (currently) "toy" project that takes relatively short alphanumeric codes and converts them into images and animations. (The SourceForge project is at http://sourceforge.net/projects/picturecode and a design document is at https://docs.google.com/file/d/0B-yO-2scTVuRSkk2NDdiZ3YzTDg/edit?usp=sharing )

I'm at a point where I'm devising operations for nesting pre-defined and user-defined codes within other codes to allow even more complex images with even shorter codes. I'm also trying to devise related operations that will assist in similarly complex, but interesting images with relatively simple code representation.

As such, one of the operations I thought would be useful is the ability to use a pre-defined or user-defined code as a mask to clip other drawing operations. I was able to get this working after I discovered that clipPath is not supported in hardware-accelerated views, and forced the view to be software-based. (My renderer checks whether we are in a mode that defines a "clipping path" and adds operations to a path instead of drawing them on the canvas, but that was kind of tedious and doesn't support all operations.)

I'm considering alternatives for switching back to a hardware-accelerated mode. One that comes to mind is creating an ALPHA_888 bitmap and drawing to that instead of creating a clipping path when I'm in that clipping mode. One advantage this would likely have is that it would be more straightforward to support arbitrary operations; I just draw them on that bitmap instead of on the main canvas when I'm in clipping mode. Once I have the bitmap, I assume I can somehow use it with drawBitmap (into another intermediate bitmap) using a Paint with an appropriate PorterDuff mode.

I expect that someday I (or anyone for that matter, since the project is on SourceForge) might reuse this component in a larger project as a lightweight way of representing graphics that can be transferred in a plain text, but short/optimized format. I see it as an animated GIF, but simpler to create and smaller to transfer.

My questions are:

1. How important is hardware acceleration in general? Is this an important feature to retain or should I give that up in favor of other features? (If others were going to use this feature, I assume they'd often want a component to be hardware-acceleration-compatible.)
2. Is masking a powerful/important operation, or is there something better I could be using instead (like pure porter-duff-filtered drawing directly to the canvas)?
3. Am I thinking along the right track for implementing complex masking?

Finally and most importantly :

• How should I use and manage bitmaps if at all (for example, the mask bitmap)? When I started the project, I noticed that it's not advisable to allocate any new objects during OnDraw. So I pre-allocated all that I could - a Paint, a PointF, a RectF, a Path, and a few others, so that I could use them during onDraw. At the moment, I'm still drawing directly to the canvas, but I'm wondering if I should be rendering to some sort of buffer, like a bitmap, on a separate thread and then just drawing the buffer to the screen during onDraw. Would that defeat the purpose of hardware acceleration (and make it not necessary to turn off hardware acceleration on the view itself in the first place)? And more importantly how/when can I safely allocate these bitmaps without offending lint and well-seasoned android developers who know that allocating memory during onDraw is bad? If I allocate the bitmap on a separate drawing thread, I may have to allocate it once for each frame of each included/embedded picture because these pictures can be animations. Or I may just want to allocate a bitmap for the current frame to assist in clipping or composing multiple pieces of the image.

It's hard to narrow this down to a very specific question. What I have is somewhere between a mess of questions and a request for general advice about features or ideas of which I might not even be aware. I'm relatively new to Java and Android development, but thoroughly familiar with C#, 2D graphics and game development. Do my questions point out any glaring holes in my understanding of how 2D animation should work on Android?

Answer 1

In reading an article about Android hardware acceleration , I stumbled across a reference to the saveLayer functions of the Canvas, which I believe are the exact pieces I was missing here.

Update: I have confirmed that saveLayer is what I'm after. Instead of applying a complex clipping region based on a path, and then drawing into that, I am calling saveLayer to create an off-screen buffer into which drawing operations will be applied, drawing one image, switching the Xfermode to SRC_IN, and then drawing the second image. This yields the intersection of the two images with the second image being the visible content. When I call restore I essentially get the second image clipped by the content of the first image, which is better than what I was trying to accomplish in the first place.