2

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.

Jerikc XIONG
  • 3,517
  • 5
  • 42
  • 71

2 Answers2

6

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.

fadden
  • 51,356
  • 5
  • 116
  • 166
  • It's so clear. Thanks. By the way, How about if I need use the camera frame to encode for live streaming? – Jerikc XIONG Jun 12 '15 at 01:54
  • The camera output can be directed to anything with a Surface, which includes MediaCodec (API 18+) and MediaRecorder (API 21+). You can find examples of H.264 encoding with MediaCodec in Grafika (https://github.com/google/grafika). – fadden Jun 12 '15 at 04:23
  • Thanks for your great help. But how about under API 18 /API 21 ? – Jerikc XIONG Jun 12 '15 at 06:02
  • Pre-API 18 you can't move the data through surfaces, which means moving it through software buffers (much slower). Whether or not that's viable depends on your needs (resolution, frame rate, etc). – fadden Jun 12 '15 at 16:42
  • You are so cool. You wrote Grafika and run bigflake.com. Great job! Do you have a blog site? I want to follow you. – Jerikc XIONG Jun 14 '15 at 02:50
  • Could you please provide your facebook/google plus/twitter id or email information? Thanks. – Jerikc XIONG Jun 24 '15 at 03:27
0

" 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 :)

Ritvik Vyas
  • 42
  • 1