개발뚱땅

GLSurfaceView

public class GLSurfaceView
extends SurfaceView implements SurfaceHolder.Callback2

An implementation of SurfaceView that uses the dedicated surface for displaying OpenGL rendering.

OpenGL 렌더링을 보여주는 전용 surface를 사용하기 위한 SurfaceView의 구현 클래스입니다. 

A GLSurfaceView provides the following features:

GLSurfaceView는 다음과 같은 기능을 제공합니다:

• Manages a surface, which is a special piece of memory that can be composited into the Android view system.
  안드로이드 뷰 시스템에 합성될 수 있는 특정한 메모리의 부분인 surface를 관리합니다.
• Manages an EGL display, which enables OpenGL to render into a surface.
  표면에 OpenGL이 그려줄 수 있도록 하는 EGL display를 관리합니다.
• Accepts a user-provided Renderer object that does the actual rendering.
  렌더링에 사용되는 사용자 제공 렌더러 객체를 사용할 수 있습니다.
• Renders on a dedicated thread to decouple rendering performance from the UI thread.
  UI스레드와 상관없이 작동하기 위해 전용 스레드로 렌터링합니다.
• Supports both on-demand and continuous rendering.
  지속적으로 작동하는 렌더링과 사용자가 요청했을때 그려주는 것을 모두 지원합니다.
• Optionally wraps, traces, and/or error-checks the renderer's OpenGL calls.
  옵션, 렌터러의 OpenGL 호출을 래핑하거나, 추적, 에러확인할 수 있습니다.
  
  

Using GLSurfaceView

GLSurfaceView 사용하기

Typically you use GLSurfaceView by subclassing it and overriding one or more of the View system input event methods.

일반적으로 GLSurfaseView를 상속받아 서브 클래스를 만들고 하나 이상의 view 시스템 입력 이벤트 메소드를 재정의하여 사용합니다.

If your application does not need to override event methods then GLSurfaceView can be used as-is.

만약 이벤트 메소드의 재정의가 필요하지 않다면, GLSurfaceView를 그대로 사용할 수 있습니다.

For the most part GLSurfaceView behavior is customized by calling "set" methods rather than by subclassing.

대부분 GLSurfaceView의 동작은 상속받아 만들지 않고 set메소드를 사용해 사용자 정의 됩니다.

For example, unlike a regular View, drawing is delegated to a separate Renderer object which is registered with the GLSurfaceView using the setRenderer(android.opengl.GLSurfaceView.Renderer) call.

예를 들어, 일반 뷰와 다르게 그리는 것은 setRenderer 메소드를 호출로 등록된 별도의 렌더러에 의해 그려집니다.

Initializing GLSurfaceView

GLSurfaceView 초기화하기

All you have to do to initialize a GLSurfaceView is call setRenderer(android.opengl.GLSurfaceView.Renderer).

GLSurfaseView를 초기화하기 위해 해야하는 것은 setRenderer를 호출하는 것입니다.

However, if desired, you can modify the default behavior of GLSurfaceView by calling one or more of these methods before calling setRenderer:

그러나 원하는 경우  setRenderer를 호출하기 전에 GLSurfaceView의 기본 동작을 수정하기 위해 다음 메소드 중에 하나 이상의 메소드를 호출할 수 있습니다:

• setDebugFlags(int)
• setEGLConfigChooser(boolean)
• setEGLConfigChooser(android.opengl.GLSurfaceView.EGLConfigChooser)
• setEGLConfigChooser(int, int, int, int, int, int)
• setGLWrapper(android.opengl.GLSurfaceView.GLWrapper)

Specifying the android.view.Surface

android.view.Surface 지정하기

By default GLSurfaceView will create a PixelFormat.RGB_888 format surface.

기본적으로 GLSurfaceView는 PixelFormat.RGB_888 형식의 surface를 만듭니다.

If a translucent surface is required, call getHolder().setFormat(PixelFormat.TRANSLUCENT).

반투명한 표면이 필요한경우, getHolder().setFormat(PixelFormat.TRANSLUCENT)를 호출하세요.

The exact format of a TRANSLUCENT surface is device dependent, but it will be a 32-bit-per-pixel surface with 8 bits per component.

TRANSLUCENT의 정확한 포멧은 디바이스에따라 다르지만, 한 픽셀당 32비트로 이루어져있다.

Choosing an EGL Configuration

EGL 설정 선택하기

A given Android device may support multiple EGLConfig rendering configurations.

지정된 안드로이드 디바이스는 여러 EGLConfig 렌더링 설정을 지원합니다.

The available configurations may differ in how many channels of data are present, as well as how many bits are allocated to each channel.

사용가능한 구성은 데이터의 채널 수와 각 채널에 몇 비트가 할당되었는지에 따라 다릅니다.

Therefore, the first thing GLSurfaceView has to do when starting to render is choose what EGLConfig to use.

그러므로, GLSurfaceView가 렌더링을 시작할 때 해야할 것은 사용할 EGLConfig를 선택하는 것 입니다.

By default GLSurfaceView chooses a EGLConfig that has an RGB_888 pixel format, with at least a 16-bit depth buffer and no stencil.

기본적으로 GLSurfaceView는 최소 16비트 버퍼와 스텐실이 없는 RGB_888 픽셀 형식의 EGLConfig를 선택합니다.

If you would prefer a different EGLConfig you can override the default behavior by calling one of the setEGLConfigChooser methods.

다른 EGLConfig를 선호하는 경우 setEGLConfigChooser 메소드를 사용해 기본 동작을 오버라이드할 수 있습니다.

Setting a Renderer

렌더러 설정

Finally, you must call setRenderer(GLSurfaceView.Renderer) to register a Renderer.

마지막으로 렌더러를 등록하기위해 setRenderer를 호출해야 합니다.

The renderer is responsible for doing the actual OpenGL rendering.

렌더러는 실제 OpenGL 렌더링을 담당합니다.

Rendering Mode

렌더링 모드

Once the renderer is set, you can control whether the renderer draws continuously or on-demand by calling setRenderMode(int). 

렌더러가 설정되면 당신은 렌더러로 계속 그릴지 호출 시 그릴지 setRendererMode를 사용해서 제어할 수 있습니다.

The default is continuous rendering.

기본값은 연속 렌더링 입니다.

Activity Life-cycle

A GLSurfaceView must be notified when to pause and resume rendering.

렌더링이 중지되고 다시 시작할 때 GLSurfaseView에 알려야 합니다.

GLSurfaceView clients are required to call onPause() when the activity stops and onResume() when the activity starts.

GLSurfaceView 클라이언트는 액티비티가 멈출때 onPause를 호출하고 액티비티가 다시 시작할 때 onResume을 호출해야합니다.

These calls allow GLSurfaceView to pause and resume the rendering thread, and also allow GLSurfaceView to release and recreate the OpenGL display.

이러한 호출은 GLSurfaseView가 렌더링 스레드를 멈추고 재개하게 하고, OpenGL 디스플레이를 해제하고 다시 생성할 수 있게 합니다.

Handling events

To handle an event you will typically subclass GLSurfaceView and override the appropriate method, just as you would with any other View.

이벤트를 처리하기 위해서 당신은 일반적으로 GLSurfaceView를 상속받아 클래스를 만들고 적절한 메소드를 재정의 할것입니다.

However, when handling the event, you may need to communicate with the Renderer object that's running in the rendering thread.

그러나 이벤트를 처리할 때, 당신은 렌더링 스레드에서 작동중인 렌더러 객체와 통신해야할 수 있습니다.

You can do this using any standard Java cross-thread communication mechanism.

당신은 표준 자바 크로스 스레드 통신 메커니즘을 사용하여 이를 수행할 수 있습니다.

In addition, one relatively easy way to communicate with your renderer is to call queueEvent(java.lang.Runnable).

게다가, 렌더러와 통신하기 쉬운 한가지 방법은 queueEvent 메소드를 호출하는 것입니다.

For example:

 class MyGLSurfaceView extends GLSurfaceView {

     private MyRenderer mMyRenderer;

     public void start() {
         mMyRenderer = ...;
         setRenderer(mMyRenderer);
     }

     public boolean onKeyDown(int keyCode, KeyEvent event) {
         if (keyCode == KeyEvent.KEYCODE_DPAD_CENTER) {
             queueEvent(new Runnable() {
                 // This method will be called on the rendering
                 // thread:
                 public void run() {
                     mMyRenderer.handleDpadCenter();
                 }});
             return true;
         }
         return super.onKeyDown(keyCode, event);
     }
 }

표준 컨테이너

컨테이너는 객체를 담는 객체이다.

이 컨테이너들은 클래스 템플릿으로 구현되어 다양한 타입의 element를 지원한다.

컨테이너는 elements를 위한 저장공간을 관리하고, element에 접근하기위한 멤버 함수를 제공한다. 접근할 때에는 직접 element에 접근할 수도 있고 iterator를 통해서 접근할 수도 있다.

컨테이너는 프로그래밍을 하면서 가장 일반적으로 사용되는 자료구조들로 이루어져있다.

동적배열(vector), 큐, 스택, 힙(priority_queue), 링크드 리스트(list), 트리(set), 연관배열(map)

컨테이너들은 몇몇 멤버함수를 공통적으로 갖는다. 

프로그래밍을 하면서 사용할 컨테이너를 고르는 경우, 컨테이너가 제공하는 기능만으로 결정하는 것이 아니라 컨테이너의 내부 구현된 방식을 이해하고 결정해야한다. 특히 순차 컨테이너의 경우 삽입, 삭제, 접근의 효율성이 차이가 난다.

스택, 큐, 우선순위 큐는 컨테이너 어답터이다.

컨테이너 어답터는 완전한 컨테이너 클래스가 아니라 기존 컨테이너 클래스에 의존해 특정한 인터페이스를 제공하는 방식이다.

컨테이너 클래스 템플릿

C++11에서 추가된 함수는 배경색을 칠했다.

순차 컨테이너

컨테이너 어답터

연관 컨테이너

순서 없는 연관 컨테이너

벡터

벡터는 크기가 변할수 있는 배열이다.

순차 컨테이너이다.

배열처럼 메모리에 연속하여 데이터를 할당하므로 인덱스로 접근이 가능하다.

배열과 다르게 크기가 커져 할당된 크기를 넘어서면 재할당하여 크기를 키운다.

다른 순차 컨테이너인 덱(deque), 리스트(list)와 비교해 벡터는 인덱스로 바로 접근하는게 빠르다.

벡터의 끝에 요소를 삽입, 삭제하는 것은 빠르지만 중간이나 앞 부분에 요소를 삽입, 삭제하는 것은 효율적이지 않다.

멤버함수

C++11에서 추가된 함수는 배경색을 칠했다.

Iterators

Capacity

Element access

Modifiers

리스트

리스트는 순차 컨테이너다.

삽입과 삭제하는데 걸리는 시간이 상수시간만큼 걸린다.

더블 링크드 리스트로 구현되어 있어서 양방향 순회가 가능하다.

벡터와 덱, 배열과 비교하면 삽입, 삭제, 요소 이동에 장점을 가지고 있고

직접 접근할 수 없는 것이 단점이다. 접근하는 데 선형 시간이 걸린다.

멤버함수

C++11에서 추가된 함수는 배경색을 칠했다.

Iterators

Capacity

Element access

Modifiers

Operations

            <TableLayout
                android:layout_width="match_parent"
                android:layout_height="match_parent"
                android:id="@+id/storyActivity_tableLayout"
                android:stretchColumns="*"
                android:shrinkColumns="*"
                >
                <TableRow
                    android:layout_width="match_parent"
                    android:layout_height="match_parent"
                    >
                    <Button/>
                    <Button/>
                    <Button/>
                    <Button/>
                    <Button/>
                </TableRow>
                <TableRow
                    android:layout_width="match_parent"
                    android:layout_height="match_parent"
                    >
                    <Button/>
                    <Button/>
                    <Button/>
                    <Button/>
                    
                </TableRow>
            </TableLayout>

stretchColums를 하면 안에 속한 것들을  너비에 맞게 늘리는 것이고

shrinkColums는 너비에 맞게 줄이는 것이다.

다음과 같은 결과가 나온다

test

getFragmentManager()는 지원이 끝나 getSupportFragmentManager()를 사용해야 한다.

프래그먼트는 어떤 동작이나 UI의 일부입니다.

여러개의 프래그먼트를 하나의 액티비티에 결합하여 창이 여러개인 UI를 만들 수 있습니다.

하나의 프래그먼트를 여러 액티비티에서 재사용할 수 있습니다.

프래그먼트는 액티비티의 모듈형 부품이라고 생각하면 됩니다.

프래그먼트는 수명주기를 가지고 있고 입력 이벤트를 수신할 수 있고, 액티비티 실행 중에 추가 및 삭제가 가능합니다.

즉, 다른 액티비티에서 다시 사용할 수 있는 하위 액티비티와 같은 개념입니다.

프래그먼트는 항상 액티비티 내에 속해야하며, 프래그먼트의 수명 주기는 호스트 액티비티의 수명 주기에 영향을 받습니다.

액티비티가 일시정지된 경우, 거기 속한 모든 프래그먼트도 일시정지 되며 액티비티가 소멸되면 모든 프래그먼트도 소멸됩니다.

액티비티가 실행중인 동안에는 각 프래그먼트를 추가, 제거하는 등 개별적으로 조작할 수 있습니다.

이러한 프래그먼트 조작(트랜잭션)을 수행하는 경우 이 것을 액티비티가 관리하는 백 스택에도 추가할 수 있습니다.

각 백 스택 항목이 발생한 프래그먼트 트랜잭션의 기록이 됩니다. 이 백 스택을 사용해 사용자가 프래그먼트 조작(트랜잭션)을 다시 되돌릴 수 있습니다. 이때 뒤로가기 버튼을 누르면 됩니다.

프래그먼트를 액티비티 레이아웃에 추가하면, 해당 프래그먼트는 액티비티의 뷰 계층 내에서 뷰그룹에 들어가고 자체적인 뷰 레이아웃을 정의합니다. (뷰그룹이란 다른 뷰를 포함할 수 있는 뷰입니다. 레이아웃, 컨테이너)

액티비티의 레이아웃 파일에서 <fragment>요소로 프래그먼트를 선언하거나 기존 뷰그룹에 추가하는 방법으로 애플리케이션 코드에서 프래그먼트를 선언하면 액티비티 레이아웃에 프래그먼트를 삽입할 수 있습니다.

수명 주기