Android Graphics 번역 7편 - SurfaceTexture와 TextureView

출처: https://source.android.com/devices/graphics/arch-st, https://source.android.com/devices/graphics/arch-tv

SurfaceTexture

SurfaceTexture는 Surface와 GLES texture의 조합이다. SurfaceTexture instance는 GLES texture로 출력되는 Surface를 제공하는 데 사용된다.

SurfaceTexture는 app이 consumer인 BufferQueue instance를 포함하고 있다. onFrameAvailable() 콜백은 producer가 새로운 buffer를 큐에 넣을 때 앱에게 알려준다. 그때, 앱은 이전에 있던 buffer를 release하는 updateTexImage()를 호출하고 대기열에서 새로운 buffer를 얻고 EGL 호출을 통해 buffer를 GLES에서 external texture로 사용할 수 있도록 한다.

External GLES textures

External GLES textures(GL_TEXTURE_EXTERNAL_OES**)는 전통적인 GLES textures(GL_TEXTURE_2D)**와는 다음과 같은 점에서 다르다.

• External textures는 BufferQueue로부터 받은 data에서 직접 textured polygon을 rendering 한다.
• External textures renderer는 기존 GLES textures renderer와 다르게 구성된다.
• External textures는 전통적인 GLES textures의 모든 활동을 수행할 수 없다.

External texture의 주요 이점은 BufferQueue 데이터로부터 직접 렌더링을 할 수 있다는 것이다. SurfaceTexture instance는 BufferQueue를 만들 때 GRALLOC_USAGE_HW_TEXTURE flag를 이용하여 consumer를 설정하고 buffer의 데이터를 GLES에서 인식할 수 있도록 한다.

SurfaceTexture는 EGL Context와 상호작용 하기 때문에 texture를 소유하는 EGL Context가 호출된 스레드에 있는 동안에만 함수를 호출할 수 있다.

Timestamps and transformations

SurfaceTexture는 timeStamp를 찾는 getTimeStamp() 함수와 transformation matrix를 찾는 getTransformMatrix()함수를 제공한다. updateTextImage()를 호출하면 imestamp와 transformation matrix가 세팅된다. BufferQueue가 전달하는 각각의 buffer는 transformation 인자와 timestamp를 포함하고 있다.

Transformation 인자는 효율성을 위해 유용하다. 몇몇 경우에서, 데이터가 잘못된 orientaion일 수 있다. 데이터를 소비자에게 보내기 전에 회전하는 대신 데이터를 수정하는 transformation을 사용하여 올바른 orientaion으로 데이터를 보낸다. transformation matrix는 데이터를 사용할 때 다른 trnasformation과 병합하여 오버헤드를 최소화 할 수 있다.

Timestamp는 시간에 의존적인 buffer source에 유용하다. 예를 들어, setPreviewTexture()함수는 생산자 interface를 camera의 결과에 연결하면 camera로부터 오는 frame은 video를 만드는데 사용 할 수 있다. 각각의 frame은 앱이 frame을 받은 시점이 아니라 캡처된 시점의 timestamp가 있어야 한다.

TextureView

TextureView는 View와 SurfaceTexture를 결합시킨 View 객체이다.

Rendering with OpenGL ES

TextureView 객체는 SurfaceTexture를 wrapping하여 콜백에 반응하고 새로운 buffer를 얻는다.한 TextureView가 새로운 buffer를 얻을 때 TextureView는 뷰에게 invalidate 요청을 하고 최신 buffer의 내용을 데이터 소스로 사용하여 그린다.

OpenGL ES(GLES)는 EGL생성 호출때 SurfaceTexture를 전달함으로써 TextureView에 렌더링 할 수 있다. 하지만 이러한 생성은 문제가 있다. GLES가 textureView에 렌더링 할 때, BufferQueue 생산자와 소비자가 같은 thread에 있으므로 buffer swap 호출이 중단되거나 실패할 수 있다.예를 들어, 한 생산자가 UI thread에서 여러 buffer를 연속적으로 빠르게 제출하는 경우 EGL buffer swap 호출은 BufferQueue로부터 buffer를 빼야 한다. 그러나 생산자와 소비자가 같은 thread에 있기 때문에 사용 가능한 buffer가 없고 swap 호출이 중단되거나 실패한다.

buffer swap이 중단되지 않게 하기 위해서 BufferQueue는 항상 대기열에서 뺼 수 있는 버퍼가 있어야 한다. 이것을 구현하기 위해서 BufferQueue는 새 buffer가 대기열에 추가될 때 이전에 얻은 buffer의 내용을 버리고 소비자가 한 번에 모든 buffer를 소비하는 것을 방지하기 위해 최소 및 최대 버퍼 수에 제한을 둔다. (만약 여러분의 큐가 세개의 버퍼를 가지고 있고, 세개 버퍼 모두 소비자가 가져간다면, 디큐할 버퍼가 없기 때문에, 버퍼 스왑 호출이 블록 되거나 실패한다. 그래서 우리는 소비자가 한번에 두개 이상의 버퍼를 획득하는 것을 제한한다.) 버퍼를 드랍시키는 것은 보통 바람직하지 않다. 그래서 이것은 보통 생산자와 소비자가 동일 프로세스에 있을 때와 같이 특수한 상황에만 허용된다

Choosing SurfaceView or TextureView

API 24 이상에서는 TextureView 대신 SurfaceView를 구현하는 것이 좋다.

SurfaceView와 TextureView는 유사한 역할을 하며 둘다 View이다. 그러나 SurfaceView와 TextureView는 다른 구현을 가진다. SurfaceView는 다른 View들과 동일한 인자를 가지지만 SurfaceView의 내용물은 렌더링 될 때 투명하다.

TextureView는 SurfaceView보다 alpha 및 회전 처리에서 우수하다. 하지만 SurfaceView는 Video위에 UI를 합성할 때 성능상의 이점을 가진다. 클라이언트가 SurfaceView로 렌더링할 때 SurfaceView는 클라이언트에 별도의 레이어를 제공한다. SurfaceFlinger는 기기에서 지원하는 경우 별도의 레이어를 hardware overlay로 구성한다. 클라이언트가 TextureView로 렌더링할 때 UI 툴킷은 TextureView의 콘텐츠를 GPU를 사용하여 뷰 계층 구조로 합성합니다. 따라서 콘텐츠를 업데이트하면 다른 View들이 다시 그려질 수 있다(예: 다른 View가 TextureView 위에 있는 경우). View 렌더링이 완료된 후 SurfaceFlinger는 앱 UI 레이어와 다른 모든 레이어를 합성하여 가시적인 모든 픽셀이 두 번 합성되게 된다.

 

 

이로써 미흡하지만 Android 공식문서의 graphics 번역을 해보았다. 보통의 앱개발자들은 아마 Surface나 SurfaceView TextureView를 직접 사용할 일은 거의 없을 것이다.. 그러나 Android 개발자라면 우리의 디바이스에 그려지는 모든 그래픽 데이터들이 어떤 방식으로 생성되고 소비되며 그려지는지 대략적으로나마 알고 있어야 한다고 생각한다. 모든 문서의 내용을 이해한 것은 아니지만 최소한 각 용어들이 어떤 의미인지, Android에서 어떤 방식으로 그래픽이 처리되는지에 대한 대략적인 감은 잡혔을거라 생각한다. 

추후에 이 지식들을 활용하며 ExoPlayer를 커스텀 해 볼 것이다.