Develop Reference

Save canvas then restore, why is that?

I often see the following code
canvas.save().
canvas translate or rotate
some drawing
canvas.restore
I don't understand why we save and then restore. What's the point of undoing what we just did! I am sure I am missing something here
Thanks

I understand this question is a bit dated, but for anyone still looking for an answer I can ELI5;
Imagine the canvas is a piece of paper, and you're tasked with drawing a picture of a robot right side up, at the bottom, and another robot upside down, slightly moved to the right, and about 40% smaller at the top. Something like this;
How would you start? What's easier to do first?
You would probably draw the bigger robot at the bottom first since it's right-side up and it's a lot easier to draw in the direction that feels more natural. So you've got the first one done, now how do you approach the second upside down robot?
You could attempt to draw it as is, but that would be a bit difficult since you're upside down.
or
You could rotate your paper 180°, move your starting point a bit, and start drawing at a smaller scale, and after you're all done you'd just rotate the paper back.
This is what canvas.save() and canvas.restore() do, they allow you to modify your canvas in any way that makes it easier for you to draw what you need. You don't need to use these methods, but they sure do simplify a lot of the process. The above would look something like
drawRobot()
canvas.save()
canvas.rotate(180)
canvas.translate(100, 0)
canvas.scale(40,40)
drawRobot()
canvas.restore()
If we look at the restore() documentation it says
is used to remove all modifications to the matrix/clip state since the last save call
and to see what those modifications are we take a look at save() it says
translate, scale, rotate, skew, concat or clipRect, clipPath
Well look at that, we did in fact use translate rotate and scale but we also did call drawRobot() so wouldn't calling restore erase our drawing? No, because it doesn't affect the drawing, only the modifications. So when we call restore it will return our canvas to the state that it was in before we started the second drawing.

What's the point of undoing what we just did!
You're not, though. If you're just going off the words, it does sound like that's what might happen, but it actually isn't.
Think of it like this:
You have a series of really complex translations and rotations you want to apply in the same onDraw(Canvas) call. Now, since every translation/rotation you apply to the Canvas happens in order, you would have to undo your last adjustments to the Canvas, or somehow calculate your new adjustments based off the previous one before drawing whatever it is you want to draw. That would get very messy, very quickly.
Using canvas.save() and canvas.restore() is a ridiculously easy way to simplify that process.
By doing adjustments that apply to the Canvas within a save/restore block, you're effectively isolating said adjustments so that whatever you want to draw next won't be affected by what you're drawing now.
Now, a little better explanation of the names:
canvas.save() is saying that I want to save the state of the current Canvas's adjustments so that I can go back to it later.
canvas.restore() is saying that I want to revert my Canvas's adjustments back to the last time I called cavas.save()
The beauty of this is in its simplicity. If you already drew whatever it is you wanted to draw during the save/restore block and you no longer need those adjustment's for your next drawing, using this let's you throw away those unnecessary adjustments and return to the state you want to start your next drawing from.
Hopefully that helps explain it!

Working with the canvas involves all manner of translate,scale,rotate,skew procedures on the canvas. The save() method preserves a state before any of the aforementioned augmentation in place, restore() rewinds to a state in time where no augmentation is injected. In other words, you can save a pre state before any transformation of the canvas, do your rotations and whatever else you want to during the process, but when your finished rewind to the state before any augmentation.

I guess the simplest way to put it is:
It removes the change in settings, but not the drawing itself.
Settings can include scaling the canvas etc., and it restores the scaling to the initial state when you called canvas.save().

When you have a background composed of multiple objects, a great way is to save this "static" background and only redraw objects that changed. This saves (processor) time.

Is there a way to draw a filled area with Canvas without using Path?

I am wondering if there is a way to draw filled areas (like a filled polygon) with the Android Canvas without using the Path class and call canvas.drawPath(...).
The reason I want to do this without Path is because I have to draw very large datasets and canvas.drawPath(...) is not hardware accelerated and therefore slow.
The performance when using canvas.drawLines(...) is much better because of hardware acceleration, however I have not found a way to draw the polygon filled using this approach (even when the lines are all connected).
Even calling paint.setStyle(Style.FILL) did not fill the polygon when using drawLines(...).
Is there a way to draw a filled-polygon without using the Path approach?
Or is there any other way to improve performance using the Canvas?

You might want to look at opengl view and use it for all the drawings you need. Definitely will be damn fast. Still, all your drawing code needs to be re-written.

You probably need to do something like :
Paint red = new Paint();
red.setColor(android.graphics.Color.RED);
red.setStyle(Paint.Style.FILL);
And use this color for your path, instead of your ARGB. Make sure the last point of your path ends on the first one, it makes sense also.

Double buffering on MIT App Inventor?

I noticed on MIT app inventor that there is no way to clear a canvas without using the .clear method. This means that you would have to manually redraw the whole screen every time you update it, right? So, what do you do in order to avoid blinking when you redraw your objects. Is there a way to have a whole canvas behind the first in order to avoid blinking, and then update it, or do you just have to deal with the blinking how it is.
I realize that it is quite possible to make an array/list of every pixel on the screen, with an int for the RGB value of each pixel, and then just draw to that list. Then you can simply copy the array to the screen to render. I think this would be excessively slow and tedious in a language as simple as MIT app inventor.

what you could do is to store your canvas as image and later assign that image to the canvas background again... see also How to Save a Canvas
You also might be interested in Scott's Paintpot mod undo and redo example here
I realize that it is quite possible to make an array/list of every pixel on the screen, with an int for the RGB value of each pixel, and then just draw to that list.
exactly, this will be slow
btw, you can find more Canvas examples (and also other stuff) from Scott here

android problem with thread

I am working with a drawing application. ON A CANVAS i able to draw something as free hand.
What i am doing here, i just store the paths in a List<path> and drawing on canvas synchronized by a thread.
when i am starting to draw for 1st time it is so smooth and speed also, but as paths are increased List<Path> size also increased so it becomes so slow , so terrible.
if i clear the List then again it becomes smoother.
But i want for every time it should be smoother. How can i do it?
IS there any way?
Thank you

I think if you are using invalidate to refresh the screen on a View, only invalidate the area where you drew the new line. So the system will not keep drawing everything. Other option is you handle the event and you keep one list for your undo redo purposes and another smaller detailed list for actual drawing.

android canvas - can i have multiple draw methods?

I have made my own canvas class which extends an imageView. My onDraw() method draws out the users gps position and I keep calling this onDraw method every time the user moves. My problem is I also want to draw out a gps trail which only needs to be drawn once (doesnt need to be updated when a user moves). I am wondering is it possible to have more than 1 onDraw method or is there any way of separating 1) the user location and 2) the gps trail??
My reason is I do not want to waste memory by redrawing the gps route everytime the users gps position changes. It is a waste.

Have you seen performance take a hit? If not, don't worry about it. I would think that this would be wasting CPU cycles if anything... not memory. So if the app seems fast enough already, don't worry about optimizing it.
If your app is a bit laggy, and you've found that the trail is the bottleneck... I would suggest caching it into a bitmap. This way, you will still have to draw the trail, but you will not have to calculate the coordinates of the trail on each frame.

I have had to solve a somewhat similar problem recently and I'll explain briefly what I did in case it's of any help.
What you can do is use multiple overlapping Views, where one may contain the background graphics that you don't want to redraw often, and a foreground View that contains the graphics that are frequently updated. Then, to gain performance, you can design the background View's onDraw() so that it is backed by a Bitmap that you then retain as a class variable. In the very first onDraw() of your background graphics, you do the relatively slow drawing to Canvas. In subsequent calls to onDraw(), you simply draw that Bitmap to Canvas.
I've just done this myself. Basically what my application does is display a number of graphical gauges. Those gauges have lots of graphics that are drawn just once (gauge face, number legends), and the pointer graphic that needs to be redrawn over and over as the model data changes. First of all, I split the background graphics and moving foreground graphics into separate overlapping Views. Now, invalidating and redrawing the foreground pointer graphic of course causes anything it overlaps to be invalidated too, so the onDraw() method for the background graphics View is being called each time the pointer View is redrawn. The background View only needs to draw the background graphics once, but retains the Bitmap that backs the canvas, and in subsequent onDraw() calls it draws this bitmap back to Canvas (which is a lot faster than initially creating the graphics using Path() objects).
Bitmap bm;
....
protected void onDraw(Canvas canvas){
if(null==bm){
bm=Bitmap.createBitmap(getMeasuredWidth(),getMeasuredHeight(),Bitmap.Config.ARGB_8888);
// do your slow vector graphics drawing to Canvas here
}
Paint drawPaint = new Paint();
drawPaint.setAntiAlias(false);
drawPaint.setFilterBitmap(false);
drawPaint.setDither(false);
canvas.drawBitmap(bm, 0, 0, drawPaint);
}

Well, there can't be more than 1 onDraw method, assuming that I understood your question correctly. You will need to think about alternate approaches about how to handle this.
#DeeV suggested, that can be a solution for you.