Can anyone tell me what the basic difference is between SurfaceView and GLSurfaceView? When should I use SurfaceView, and when should I use GLSurfaceView?
I read some already answered questions on Stack Overflow, but they did not satisfy my queries.
Any help would be appreciated.
A GLSurfaceView is a SurfaceView that you can render into with OpenGL. Choosing between them is simple:
If you're familiar with OpenGL and need what it provides, use a GLSurfaceView.
Otherwise, use a SurfaceView.
OpenGL is low-level. If you're not already familiar with it, it's an undertaking to learn. If you only need 2D drawing, SurfaceView uses the high-level, reasonably high-performance Canvas. It's very easy to work with.
Unless you have a strong reason to use a GLSurfaceView, you should use a regular SurfaceView. I would suggest that if you don't already know that you need GL, then you probably don't.
GLSurfaceView is the primary building block for 3D applications as View is for 2D applications. It is widely used not only in 3D games but also multimedia applications such as camera to create special preview affect.
GLSurfaceView extends SurfaceView and additionally owns a render thread and a render object set by the client. The render thread keeps running , continuously or on-demand, and delegates to the render object to draw frame using OpenGL API. For both SurfaceView and GLSurfaceView, rendering is performing in a separate thread other than main thread. The difference is with SurfaceView the rendering thread is created by client while with GLSurfaceView it is created by the system. What's more, GLSurfaceView will internally handle the synchronization between main thread and rendering thread.
For more, check out this and this
SurfaceView
AFAIK Canvas is Simple to implement and effective in 2D drawing but 3D drawing are not supported on it
GLSurfaceView
If you want to design some 3D Game then you shold go with GLSurfaceView and OGLES
Whats my experience is if you just want to do 2D processing then select Canvas because its easier to implement and effective compare to GLSurfaceView.
Related
As we know, we can choose TextureView, SurfaceView and GLSurfaceView for android camera preview.
Which one is best choice for camera preview ? I'm focused on the camera performance.
From a performance perspective, SurfaceView is the winner.
With SurfaceView, frames come from the camera and are forwarded to the system graphics compositor (SurfaceFlinger) with no copying. In most cases, any scaling will be done by the display processor rather than the GPU, which means that instead of scanning the pixels once for scaling and again for scan-out, they're only scanned once.
GLSurfaceView is a SurfaceView with some wrapper classes that handle EGL setup and thread management. You can't use OpenGL ES on a Surface that is receiving camera frames, so you're doing extra work with no benefit. (The overhead is minor one-time setup, not per-frame, so you likely won't be able to measure the difference.)
TextureView receives the frames in a SurfaceTexture as an "external" OpenGL ES texture, then uses GLES to render them onto the app's UI surface. The scaling and rendering are performed by the GPU, and the result is then forwarded to SurfaceFlinger. This is the slowest option, but also the most flexible of the Views.
If you'd like to learn more about how the system works, see the Android Graphics Architecture document.
" The SurfaceView creates a new window in the Android Windowsystem. Its advantage is, that if the SurfaceView gets refreshed, only this window will be refreshed. If you additionally update UI Elements (which are in another window of the windowsystem), then both refresh operations block themselfes (especially when ui drawing is hardwaresupported) because opengl cannot handle multi thread drawing properly.
For such a case it could be better using the TextureView, cause it's not another window of the Android Windowsystem. so if you refresh your View, all UI elements get refreshed as well. (Probably) everything in one Thread.
Hope I could help some of you! "
Source : stackoverflow.com
GLSurfaceView is a SurfaceView with a wrapper class that does all the EGL setup and inter-thread messaging for you.
Its completely upto you what you put to use.. They have their pros and cons over eachother :)
I plan to write a 2D drawing app with a zoomable user interface. With the app the user should be able to transform (translate and scale) drawn paths (and of course the UI). I assume that there will be up to 500 paths at the same time.
Now, I am wondering which view to start off with (View, SurfaceView or GLSurfaceView ) in order to provide acceptable performance. I read a couple of posts [1-6] including the once on android developer guide and am still not 100% sure which view to use.
According to the presentation at Google I/O 2009 (http://youtu.be/U4Bk5rmIpic?t=45m10s) and own experiences canvas (View and SurfaceView) doesn't seem to be performing fast enough when handling more than 100 paths.
Does anyone see a possibility in implementing the app using canvas or is OpenGL the way to go?
[1] Android: Deciding between SurfaceView and OpenGL (GLSurfaceView)
[2] SurfaceView or GLSurfaceview?
[3] Difference between SurfaceView and View?
[4] http://pierrchen.blogspot.jp/2014/03/anroid-graphics-surfaceview-all-you.html
[5] Difference between SurfaceView and ImageView
[6] Difference between SurfaceView and GLSurfaceView in Android
Because of your performance concerns, you will need to use hardware rendering. Displays keep getting denser, so touching every pixel in software is getting slower.
If you want to draw with a Canvas, you must render to a custom View, with hardware acceleration enabled. Canvas rendering on a Surface is always done with software.
SurfaceView and GLSurfaceView are nearly the same thing; GLSurfaceView just has some helper functions that take care of some of the housekeeping for you. You can use GLES to render on SurfaceView and TextureView. There are multiple examples of this in Grafika.
If you want to know what's going on under the hood, see the System-Level Graphics Architecture doc.
You may want to consider the use of an open-source 2D game engine. That'll handle the EGL setup, should provide code for GLES font rendering, and so on.
I want to make a "2d game" using graphics from the ressources for the characters.
Now I'm asking myself what is the best solution.
I was searching a lot in the net finding the two different options.
A) Creating a custom view, adding it to the layout showing a AnimationDrawable or
B) Using the SurfaceView directly painting on it
Whereas a) is usually called slow and unperformant for games I tried to find a solution for b).
But so far all tutorials are only made with one image moving around on the surfaceView or animating geometric shapes (which isn't really what I had in mind).
Finding tutorials for "how to draw AnimationDrawable on SurfaceView" are very rare.
So I thought I might load all animation frames of my character into an array drawing each call the right one on the SurfaceView. But that sounds like a lot of overhead to me. Should I abandon the SurfaceView?
Has anyone a good idea what would be the best way to animate - lets say 10 characters + "background" on my screen?
You have (at least) three options:
Draw on SurfaceView surface with a Canvas. This will use software rendering and be relatively slow.
Instead of a SurfaceView, draw on a custom View with a Canvas. This will be hardware accelerated, with some limitations.
Draw on SurfaceView surface with OpenGL ES. This will be hardware accelerated, but you have to figure out how GLES works.
You should also consider (4) use an open-source 2D game engine and don't worry about what it's actually doing.
If you want an example, Android Breakout is a simple but complete 2D game written for GLES and GLSurfaceView. A more evolved set of EGL/GLES helpers can be found in Grafika, which uses GLSurfaceView, SurfaceView, and TextureView to accomplish various things. It also demonstrates the use of the hardware scaler to improve efficiency on larger displays.
Long description of the Android graphics architecture is available here.
Okay, I'm not sure this is the best option but I found a tutorial for using "Sprite Sheets".
http://www.edu4java.com/en/androidgame/androidgame4.html
So far this seems to be a good solution. OpenGL seemed a bit too much to me but perhaps I'm not good at Shader Language etc.
So if anyone finds a better solution, please let me know.
Is there a way to decide up front based on the expected complexity of a game/app in the planning phase whether to use regular Canvas drawing in a SurfaceView or to go with OpenGL?
I've been playing around with a Canvas and only need 2D movement, and on a fairly new phone I'm getting pretty decent performance with a bunch of primitive objects and a few bitmaps running around the screen on a solid background.
Is it fair to say that if I'm going to be drawing background images and increasing the number of objects being moved and drawn on top of them that I should go straight to OpenGL?
All I can say is that it depends on how many sprites you're gonna use. Chris Pruett from Google has also documented this part very well.
Google I/O 2009 and Google I/O 2010.
Below is a picture from one of his slides that are related to your topic:
With that knowledge, you should go with OpenGL using the draw_texture extension. Remember to query out the string and check if draw_texture is supported on the actual device.
For further information that are related to game development in general, see this.
SurfaceView
A GLSurfaceView is a SurfaceView that you can render into with OpenGL.
Choosing between them is simple:
If you're familiar with OpenGL and need what it provides, use a
GLSurfaceView. Otherwise, use a SurfaceView. OpenGL is low-level. If
you're not already familiar with it, it's an undertaking to learn. If
you only need 2D drawing, SurfaceView uses the high-level, reasonably
high-performance Canvas. It's very easy to work with.
Unless you have a strong reason to use a GLSurfaceView, you should use
a regular SurfaceView. I would suggest that if you don't already know
that you need GL, then you probably don't.
OpenGL
OpenGL would be able to handle the rotations and scaling easily.
Honestly, you would probably need to learn a lot of OpenGL to do this,
specifically related to the topics of:
Geometry Lighting (or just disabling it) Picking (selecting geometry
to draw on it) Pixel Maps Texture Mapping Mipmapping Also, learning
OpenGL for this might be overkill, and you would have to be pretty
good at it to make it efficient.
Instead, I would recommend using the graphic components of a game
library built on top of openGL, such as:
Cocos2d
libgdx
Any of the engines listed here
Source
Difference between SurfaceView and GLSurfaceView in Android
Android: Canvas vs OpenGL
I am building aprogram that needs to do drag/drop operations of images. Now on a Canvas it is quite easy, and I might chose this. However, I am also interested in using GLSurface View?? Now what I am seeing in examples is either a drag/drop tutorial on Canvas or drawing on GLSurface view. I am wondering if handling touch events is more complicated with GLSurface view? Is it possible to handle touch events with GLSurfaceView. Also why would one chose GLSurface view for rendering images vs. a Canvas? How does one chose between Canvas vs. GLSurfaceView?
It's really just a choice between two APIs.
Canvas:
knows about common Android framework classes like Bitmap
many convenient functions
can draw into bitmaps for saving to the SDCard
GLSurfaceView:
good for using the tried-and-true OpenGL API
designed for redrawing rapidly at a certain framerate
3D drawing
These are just a few aspects of the debate. I don't think either of them has the upper hand on event processing. I'd say that it makes more sense to use Canvas if you are working primarily with the Android SDK, whereas GLSurfaceView is an especially good option for apps using the OpenGL APIs via the NDK.