The efficiency about android canvas drawing

I've been wondering if canvas has a limit boundary.

I mean if I use functions such asdrawline(), drawbitmap(), drawcircle(), does android really draw something on the canvas and waste some CPU cycles??

because after all the drawing functions, the actual picture print on the screen is decided by the screen size. And if I draw on something that is out of screen size, it doesn't show up.

I want to do some small detail on my canvas by calling lots of drawing functions and make my surface "bling bling". If it is out of bound I don't want to use them, if they make my drawing slow down.

I am working on a little ga开发者_如何学编程me by the structure of surfaceview, Thanks for any advice.

for Example:

I have a robot walking from a <-> b OUTSIDE the screen.

it takes 20 drawing functions to draw a robot walking picture on the canvas. If I scroll the screen, then I can see the robot.

So if the drawing function outside the screen really takes as much time as draw on screen. I have to detect that only if the robot's position can be seen by the user, then I draw. otherwise, i don't.

if the drawing function doesn't waste much CPU cycles, then I can just draw everytime even if the current screen cannot see the robot.

Another thing that can speed up canvas drawing when your canvas covers the entire screen is to use a theme that has no background. The default theme has at least a color background drawable and that results in slower draw times when you put your views over top of it, even if your view fills the whole screen.

use a theme such as:

    <style name="Theme.NoBackground" parent="android:Theme">
        <item name="android:windowBackground">@null</item>
    </style>
</resources>

Romain Guy has a great description of this phenomenon at http://www.curious-creature.org/2009/03/04/speed-up-your-android-ui/

Your canvas is backed by your bitmap (2D), or openGL (3D,which I have no experience with). All drawing on your canvas is clipped to the clipping rectangle, which you can grow, shrink, intersect with new rectangles or paths, etc. So, you really want to manage your clipping rectangles before you draw into your canvas, especially if it's backed by a large bitmap. If you clip to a region that's equal to the screen size you will save CPU cycles. If your game is a scroller type game, you can clip to a region larger than the screen size and pan around, drawing offscreen occasionally to update the area that's coming onto the screen. if your game has infinite scrolling in all directions then you'll want to have multiple smaller canvases that you can draw into all around your main central canvas, and flip them around left to right, top to bottom depending on the directions of your scrolling game. One large bitmap with one canvas might have too big of a memory footprint for a small device.