I am currently having problems with multiple surface views and the clipping of one of the single views to get it to appear as a circle. It is best described in images:
So in this view i have 2 surface views, the full screen one which is showing a preview of the camera and then the top which is playing back a file with a MediaPlayer. I have gotten the top one to be above the preview with the following line:
surfaceView.setZOrderMediaOverlay(true);
Now as you can see i have attempted to mask this to a circle with the following code:
#Override
protected void dispatchDraw(Canvas canvas) {
Path clipPath = new Path();
clipPath.addCircle(getWidth() / 2, getHeight() / 2, getWidth() / 2, Path.Direction.CCW);
canvas.clipPath(clipPath);
super.dispatchDraw(canvas);
}
But it doesn't appear to have quite worked out. I initially thought this was a problem with my masking code but turns out the if i remove the preview surface view, like in the following image, the masking works fine
Anyone have any ideas as to why this is occurring or how to fix it at all :S?
Thanks for your help
Bear in mind that a SurfaceView has two parts, the Surface and the View, and that the Android graphics system uses multiple layers.
All of your Views live on a single layer, usually referred to simply as "the View UI layer". Views can be placed on top of or below each other because they're all being rendered into the same buffer of pixels.
Surfaces appear on their own layers. By default, the SurfaceView's Surface is below (behind) the View UI layer. The SurfaceView's View part is just a transparent rectangle that the View system uses for layout. If you draw on that View (by subclassing SurfaceView and overriding a draw method), you're rendering pixels that overlap the Surface, making them opaque. This is an easy way to mask the Surface.
Your mini-player Surface uses setZOrderOnTop(), which sets the layer for that SurfaceView's Surface to be on top (in front) of the View UI. This is handy if your Surface is partially transparent, as it lets you see the Views behind it. However, anything you draw on the SurfaceView's View will also appear behind it, so it will no longer work as a mask.
The trouble with what you're trying to do is that you want to have the lower Surface visible through the upper Surface at the corners. You can't simply mask those pixels off with another layer -- you need to make them transparent on the video playback layer itself. This is a bit tricky, as you will need to feed the video into a GLES texture and then render it.
See also the graphics architecture doc.
Related
Working with a SurfaceView to make a 2d game i do not know who to put a background image in it efficiently.
I want to avoid drawing it each frame because it is an static image, any help?
The SurfaceView's Surface is a single layer. You can specify a dirty rect to reduce your draw area when you lock the Canvas, but you have to draw everything in the rect every frame -- background and all.
You could use a pair of SurfaceViews, one at the default Z-ordering, one at "media" depth. Use SurfaceView.setZOrderMediaOverlay() to do that. The layers will be composited by the system before being rendered.
If you were using OpenGL ES rather than Canvas, it'd generally be more efficient to just redraw the background from a texture each time. (If HWC runs out of overlays, that's essentially what SurfaceFlinger is doing anyway.)
See the "multi-surface test" in Grafika for an example of using multiple overlapping surfaces.
I have a video view. This view is contained inside a custom FrameLayout called VideoStructure, where I can put also a channel logo or things alike.
Under normal conditions, the video is hardware accelerated, so the view is (i suppose) really a transparent "black hole", while the video is decoded & rendered by the relevant hardware.
My question is, if I override draw() in the Video View's container (the VideoStructure extends FrameLayout in the image) to draw some stuff (ie. the circle in the image) OVER the video -I'm overriding draw(), not onDraw()- will this break the hardware acceleration? Can I expect a big performance hit for doing this?
It should have no effect on performance.
SurfaceViews have two parts, the "view" part, and the "surface" part. The "view" part is a transparent hole that fits in with the other views, the "surface" part is a completely independent layer that is composited with the view layer by the system. The video is being sent to the "surface" part.
If you override SurfaceView's "view" renderer, you'll get a hardware-accelerated Canvas for a View that is normally completely transparent (so if you erase it, you better use an alpha of zero and the correct transfer mode).
If you attempt to render on the "surface" part, by getting a Canvas from lockCanvas(), you will either fail (because the video effectively has it locked), or succeed and prevent video from being written to it.
The system compositor is going to have to blend the "view" and "surface" layers no matter what appears in the "view" layer, so making a few more pixels opaque isn't going to have a measurable impact.
Update: see the graphics architecture doc for more details on Surfaces and composition.
I have a surfaceview in my activity. Initially some circles are drawn using
Canvas c = SurfaceView.getHolder().lockCanvas();
and
SurfaceView.getHolder().unlockCanvasAndPost(c);
Later on I want to draw on a very small part of the surfaceview. I do not want to redraw the whole surfaceview. Is it possible to update just the required part?
Use lockCanvas(Rect dirty) instead. Pass in the area you want to redraw.
Note that dirty is an in-out parameter. The Rect may be expanded to cover a larger area, and you need to set every pixel it covers. So if (for example) SurfaceView no longer has access to the previous pixels, it'll expand Rect to cover the entire surface.
Because SurfaceView is double- or triple-buffered, the implementation will copy chunks of pixels from the previous buffer. Since the Canvas you get from a SurfaceView is never hardware-accelerated, specifying a dirty rect is often a performance win.
I'm struggling to understand the process of drawing to SurfaceView and therefore the whole Surface/Canvas/Bitmap system, which is used in Android.
I've read all articles and API documentation pages, which I was able to find on android-developers site, a few tutorials of android graphics, LunarLander source code and this question.
Please tell me, which of these statements are true, which are not, and why.
Canvas has its own Bitmap attached to it. Surface has its own Canvas attached to it.
All View's of window share the same Surface and thus share the same Canvas.
SurfaceView is subclass of View, which, unlike other View's subclasses and View itself, has its own Surface to draw in.
There is also one additional question:
Why is there a need for a Surface class, if there is already a Canvas for high-level operations with bitmap. Give an example of a situation where Canvas is non-suitable for doing work which Surface can do.
Here are some definitions:
A Surface is an object holding pixels that are being composited to the screen. Every window you see on the screen (a dialog, your full-screen activity, the status bar) has its own surface that it draws in to, and Surface Flinger renders these to the final display in their correct Z-order. A surface typically has more than one buffer (usually two) to do double-buffered rendering: the application can be drawing its next UI state while the surface flinger is compositing the screen using the last buffer, without needing to wait for the application to finish drawing.
A window is basically like you think of a window on the desktop. It has a single Surface in which the contents of the window is rendered. An application interacts with the Window Manager to create windows; the Window Manager creates a Surface for each window and gives it to the application for drawing. The application can draw whatever it wants in the Surface; to the Window Manager it is just an opaque rectangle.
A View is an interactive UI element inside of a window. A window has a single view hierarchy attached to it, which provides all of the behavior of the window. Whenever the window needs to be redrawn (such as because a view has invalidated itself), this is done into the window's Surface. The Surface is locked, which returns a Canvas that can be used to draw into it. A draw traversal is done down the hierarchy, handing the Canvas down for each view to draw its part of the UI. Once done, the Surface is unlocked and posted so that the just drawn buffer is swapped to the foreground to then be composited to the screen by Surface Flinger.
A SurfaceView is a special implementation of View that also creates its own dedicated Surface for the application to directly draw into (outside of the normal view hierarchy, which otherwise must share the single Surface for the window). The way this works is simpler than you may expect -- all SurfaceView does is ask the window manager to create a new window, telling it to Z-order that window either immediately behind or in front of the SurfaceView's window, and positioning it to match where the SurfaceView appears in the containing window. If the surface is being placed behind the main window (in Z order), SurfaceView also fills its part of the main window with transparency so that the surface can be seen.
A Bitmap is just an interface to some pixel data. The pixels may be allocated by Bitmap itself when you are directly creating one, or it may be pointing to pixels it doesn't own such as what internally happens to hook a Canvas up to a Surface for drawing. (A Bitmap is created and pointed to the current drawing buffer of the Surface.)
Also please keep in mind that, as this implies, a SurfaceView is a pretty heavy-weight object. If you have multiple SurfaceViews in a particular UI, stop and think about whether this is really needed. If you have more than two, you almost certainly have too many.
Here is a very basic and simple conceptual overview of how interaction happens among the Window, Surface, Canvas, and Bitmap.
Sometimes, a visual representation helps a lot in understanding twisted concepts.
I hope this graphic could help someone.
A Bitmap is simply a wrapper for a collection of pixels. Think of it as an array of pixels with some other convenient functions.
The Canvas is simply the class that contains all the drawing methods. It is similar to the Graphics class in AWT/Swing if you are familiar with that. All the logic on how to draw a circle, or a box, etc is contained inside Canvas. A canvas draws on a Bitmap or an open GL container but there is no reason why in the future it could be extended to draw onto other types of rasters.
SurfaceView is a View that contains a Surface. A surface is similar to a bitmap (it has a pixel store). I do not know how it is implemented but I'd imagine it is a some kind of Bitmap wrapper with extra methods for things that are directly related to screen displays (That is the reason for a surface, a Bitmap is too generic). You can get a Canvas from your Surface which is really getting the Canvas associated with the underlying Bitmap.
Your questions.
1.Canvas has its own Bitmap attached to it. Surface has its own Canvas attached to it.
Yes, a canvas operates on a Bitmap (or an open GL panel). Surface gives you a Canvas that is operating on whatever Surface is using for its Bitmap style pixel store.
2.All View's of window share the same Surface and thus share the same Canvas.
No. You could have as many surface views as you want.
3.SurfaceView is subclass of View, which, unlike other View's subclasses and View itself, has its own Surface to draw in.
Yes. Just like ListView is a subclass of View that has its own List data structure. Each subclass of View does something different.
I'm struggling to understand the process of drawing to SurfaceView and therefore the whole Surface/Canvas/Bitmap system, which is used in Android.
I've read all articles and API documentation pages, which I was able to find on android-developers site, a few tutorials of android graphics, LunarLander source code and this question.
Please tell me, which of these statements are true, which are not, and why.
Canvas has its own Bitmap attached to it. Surface has its own Canvas attached to it.
All View's of window share the same Surface and thus share the same Canvas.
SurfaceView is subclass of View, which, unlike other View's subclasses and View itself, has its own Surface to draw in.
There is also one additional question:
Why is there a need for a Surface class, if there is already a Canvas for high-level operations with bitmap. Give an example of a situation where Canvas is non-suitable for doing work which Surface can do.
Here are some definitions:
A Surface is an object holding pixels that are being composited to the screen. Every window you see on the screen (a dialog, your full-screen activity, the status bar) has its own surface that it draws in to, and Surface Flinger renders these to the final display in their correct Z-order. A surface typically has more than one buffer (usually two) to do double-buffered rendering: the application can be drawing its next UI state while the surface flinger is compositing the screen using the last buffer, without needing to wait for the application to finish drawing.
A window is basically like you think of a window on the desktop. It has a single Surface in which the contents of the window is rendered. An application interacts with the Window Manager to create windows; the Window Manager creates a Surface for each window and gives it to the application for drawing. The application can draw whatever it wants in the Surface; to the Window Manager it is just an opaque rectangle.
A View is an interactive UI element inside of a window. A window has a single view hierarchy attached to it, which provides all of the behavior of the window. Whenever the window needs to be redrawn (such as because a view has invalidated itself), this is done into the window's Surface. The Surface is locked, which returns a Canvas that can be used to draw into it. A draw traversal is done down the hierarchy, handing the Canvas down for each view to draw its part of the UI. Once done, the Surface is unlocked and posted so that the just drawn buffer is swapped to the foreground to then be composited to the screen by Surface Flinger.
A SurfaceView is a special implementation of View that also creates its own dedicated Surface for the application to directly draw into (outside of the normal view hierarchy, which otherwise must share the single Surface for the window). The way this works is simpler than you may expect -- all SurfaceView does is ask the window manager to create a new window, telling it to Z-order that window either immediately behind or in front of the SurfaceView's window, and positioning it to match where the SurfaceView appears in the containing window. If the surface is being placed behind the main window (in Z order), SurfaceView also fills its part of the main window with transparency so that the surface can be seen.
A Bitmap is just an interface to some pixel data. The pixels may be allocated by Bitmap itself when you are directly creating one, or it may be pointing to pixels it doesn't own such as what internally happens to hook a Canvas up to a Surface for drawing. (A Bitmap is created and pointed to the current drawing buffer of the Surface.)
Also please keep in mind that, as this implies, a SurfaceView is a pretty heavy-weight object. If you have multiple SurfaceViews in a particular UI, stop and think about whether this is really needed. If you have more than two, you almost certainly have too many.
Here is a very basic and simple conceptual overview of how interaction happens among the Window, Surface, Canvas, and Bitmap.
Sometimes, a visual representation helps a lot in understanding twisted concepts.
I hope this graphic could help someone.
A Bitmap is simply a wrapper for a collection of pixels. Think of it as an array of pixels with some other convenient functions.
The Canvas is simply the class that contains all the drawing methods. It is similar to the Graphics class in AWT/Swing if you are familiar with that. All the logic on how to draw a circle, or a box, etc is contained inside Canvas. A canvas draws on a Bitmap or an open GL container but there is no reason why in the future it could be extended to draw onto other types of rasters.
SurfaceView is a View that contains a Surface. A surface is similar to a bitmap (it has a pixel store). I do not know how it is implemented but I'd imagine it is a some kind of Bitmap wrapper with extra methods for things that are directly related to screen displays (That is the reason for a surface, a Bitmap is too generic). You can get a Canvas from your Surface which is really getting the Canvas associated with the underlying Bitmap.
Your questions.
1.Canvas has its own Bitmap attached to it. Surface has its own Canvas attached to it.
Yes, a canvas operates on a Bitmap (or an open GL panel). Surface gives you a Canvas that is operating on whatever Surface is using for its Bitmap style pixel store.
2.All View's of window share the same Surface and thus share the same Canvas.
No. You could have as many surface views as you want.
3.SurfaceView is subclass of View, which, unlike other View's subclasses and View itself, has its own Surface to draw in.
Yes. Just like ListView is a subclass of View that has its own List data structure. Each subclass of View does something different.