Chapter 7 : Graphics APIs(1)

김형준의 개인세상... | 멋짐이
http://blog.naver.com/communist105/90002038614

거의 모든 iTV 어플리케이션은 화면 위에 어떤 형태든 사용자 인터페이스(user interface;UI)를 나타낼 필요성이 있다. 이 장에서는, MHP와 OCAP의 그래픽스 모델이 어떻게 작동하는지 살펴보고, 어플리케이션의 필요한 그래픽 장치가 어떻게 구성되어 있는지에 대해서 살펴 본다. 또한 비디오 화면과 그래픽 화면이 어떻게 통합되는지와 같은 높은 수준의 문제들과 사용가능한 UI 도구(widget)와 리모컨이나 키보드로 부터의 입력이 어떻게 다뤄지는지도 살펴 본다.

 

PC에서 어플리케이션을 개발하는 것과, DTV에서 어플리케이션을 개발하는것 사이에 가장 큰 차이점 중에 하나가 그래픽을 제어하는 방법일 것이다. DTV 환경에서의 개발자들은 그래픽 모델, 디스프레이 장치의 구성과 어플리케이션에 비디오를 통합시키는 문제, 제한된 TV 화면에서 UI가 잘 동작하도록 하는 등의 문제에 대한 특이 사항들을 인식하고 있어야 한다.

 

Java Abstract Window Toolkit(AWT)는 사실 PC환경에서 사용되어 지도록 설계된 것이고, 앞서 언급했던 DTV에서 고려되어야 할 요소들을 썩 잘 포함하고 있지는 않다. AWT가 소비 가전 기기를 개발하는 데 있어서 발생되는 문제들을 처리하도록 설계되어 있지 않기 때문에, 사실 놀랄만한 일도 아니다.

 

이러한 문제를 해결하기 위해서, MHP와 OCAP은 다른 표준들을 차용했고, 특히 그래픽 인터페이스를 위해서 HAVi API에서 상당한 부분을 차용했다. HAVi(Home Audio/Video Interoperability) 표준명세는 소비가전 기기내에서 비디오, 오디오 스트리밍과 관련된 내용들을 잘 정의하고 있다. 더욱 관심을 가질만한 것은, HAVi에서는 소비 가전 기기에서 사용되기 위한 다양한 Java UI들을 정의하고 있다는 것이다.

 

DVB에서는 적당한 솔루션이 이미 있다면, 발생된 문제를 해결하기 위해서 새로운 솔루션을 발명하는 것을 지양하지 않기 때문에, DVB는 HAVi API를 MHP의 UI 솔루션으로 채택했다. 기술적으로, 원래 HAVi에서 사용한 GUI 요소들과 구별하기 위해서, MHP에서 사용하는 UI 클라스(class)들을 HAVi Level 2 GUI라고 한다.

 

DTV 어플리케이션에서 만날 수 있는 여러 문제를 HAVi에서 어떻게 해결하는지 살펴 보기 전에, 이 문제들이 대체 무엇인지에 대해서 좀 더 자세히 살펴볼 필요가 있다. 이러한 문제를 야기 시키는 가장 큰 문제는 바로 비용이다. : DTV 수신기는 비용에 매우 민감해서, 일반적으로 고사양이 될 수 없다. 이것은 DTV 수신기의 그래픽 성능에 특히 영향을 미친다. 이와 관련해서 나중에 자세히 다시 다룰 것이지만, 지금은 TV 화면에 나타나는 DTV 소프트웨어를 개발할 때, 고려해야할 아래의 사항 부터 먼저 살펴 본다.

 

 - 픽셀 구성 비율 : 비디오와 TV 어플리케이션은 일반적으로 정사격형이 아닌 픽셀을 사용한다. 반면에 컴퓨터 그래픽 API들은 픽셀이 정사각형의 형태라는 것을 가정한다. 이것은 TV와 컴퓨터 디스플레이 장치가 화면 비율은 동일하다 하더라도, 해상도의 차이가 있기 때문이다.

 설상 가상으로, 어떤 수신기에서는 분리된 그래픽 제어기를 가지고 있어, 그래픽과 비디오 층이 스크린 위에 무엇인가를 그리기 전에는 통합되지 않는다. 두 층이 각각의 픽셀 모양을 가지고 있으면(그림 7.1에서 보는 바와 같이) 비디오 위에 올라오는 어플리케이션이 정확한 픽셀 값을 이용해서 표현되기는 매우 어렵고, 어떤 수신기에서는 심지어 불가능하기 까지 하다.

 - 화면 비율 변화 : 픽셀의 구성 비율이 다른것 처럼, TV신호의 화면 비율 자체도 4:3이 될 수도 있고, 16:9가 될 수도 있다. 여기에 그치지 않고, 같은 비율을 가지고 있는 이미지가 다른 화면 비율을 가지고 있는 TV에 표현될 때, 다른 방식으로 표현된다는 것이다. 화면의 비율과 그림의 비율이 다른 것은 TV에 의해서 변경될 수도 있고, 사용자에 의해서 변경될 수도 있다. 두 경우 모두에서 해당 비율로 만들어 지지 않은 그래픽 요소나 이미지에 미치는 영향은 해당 이미지를 늘리거나 줄어야 하는 작업 때문에 개발자들의 시각에서 반가울리가 없는 것이다. 그림 7.2는 화면 비율 변화에 대해서 적용가능한 접근 방법에 대해서 나타내었다.

 - 반투명과 투명 : 시청자가 그래픽 요소 아내에 있는 어떤 것을 볼 수 있도록 하기 위해서 어떻게 그래픽 요소를 투명하게 만들것인가? 만약 Java 2 플랫폼을 사용하고 있다면, AWT의 Java 2 버전에서 지원하는 투명요소를 사용할 수 있겠지만, 안타깝게도, 우리는 Java 2 플랫폼을 사용한다고 보장할 수 없는 현실이다.

 - 컬러 공간 문제 : RGB 컬러 공간을 TV 신호가 사용하는 YUV 컬러 공간으로 어떻게 대응 시킬 것인가? 이것은 보기 보다 복잡한 문제 인데, 두 컬러 공간은 정확하게 일치하지 않기 때문이다.

 - 윈도우 관리자의 부재 : 많은 DTV 수신기에서 윈도우 관리자는 너무 복잡해서, 무엇인가 그리고자 하는 화면의 영역을 확보하는데 있어서 어플리케이션은 다른 방법이 필요하다. 이것은 DTV 어플리케이션은 표준 Java나 PC 어플리케이션과 다른 형태로 여러 어플리케이션이 함께 존재한다는 것을 의미한다. 미들웨어 표준 마다 각각 이 문제를 해결하기 위해서 나름의 접근 법을 사용하고 있고, 이와 관련해서는 이 장의 뒷 부분에서 좀더 자세히 살펴볼 것이다.

 - UI의 차이점 : TV같은 저해상도 장치나, 어플리케이션의 다른 형태들은 컴퓨터 스타일의 GUI에서 탈피하여야 한다는 것을 의미한다. 이러한 어플리케이션들은 새로운 형태의 GUI 메타포어가 필요하고, 특히 사용자가 상호작용하기 위한 수단이 리모컨이 유일한 경우에는 더욱 그렇다.

 - 자유롭게 움직이는 커서의 부재 : 많은 DTV 수신기에서 마우스와 같은 포인팅 장치를 지원하지 않기 때문에, 네비게이션은 상하좌우키나 몇개의 버튼 만으로 가능해야 한다. 이것은 복잡한 네비게이션 모델은 어울리지 않는 다는 의미 이다.

 

 

 

그림 7.1 픽셀 구성 비율이 비디오 층(회색 픽셀)과 그래픽 층(검은 픽셀) 사이에 차이가 존재할 수 있다.

 

 

 

그림 7.2 수신기는 화면 구성 비율 전환을 다양한 방법으로 적용시킬 수 있다. 예를 들면 a) 4:3 이미지를 16:9 화면에 표시하는 것, b) 16:9 이미지를 4:3화면에 표시하는 것

 

 

 

 

이러한 차이점을 살펴 보면, 개발자들이 그래픽과 관련된 문제에 대해 생각해 봐야 한다는 것이 크게 새로운 것이 아니라는것을 알 수 있다. 그러나, 이러한 차이점에 대해서 본격적으로 논의하기 전에 데스크탑 Java와 DTV 어플리케이션에서 사용하는 Java간의 유사 영역부터 살펴 보자.

 

어플리케이션이 PC와 유사한 분위기나 느낌을 가지는 GUI를 개발하는 것을 원하지 않더라도, AWT 어플리케이션 개발과 관련된 많은 강의 들이 여기에서도 적용 가능하다. MHP는 Java 1.1.8 에서 정의한 AWT의 부분 집합들과, HAVi UI 클라스들을 추가하고, 또 PersonalJava 1.2a에서도 몇몇 요소들을 가져와 사용한다. TV 환경의 제약으로 인한 몇몇 차이점이 있기는 하지만, 대부분의 경우, MHP와 OCAP에서 그래픽과 관련해서 AWT로 어플리케이션을 만드는 경우는 큰 어려움에 봉착하지는 않는다.

 

차이점은 MHP에서 추가한 확장 API들에서 나타나기 시작한다. HAVi UI 클라스(class)는 org.havi.ui 패키지에 포함되어 있고, 수신기가 수행해야 하는 많은 그래픽과 관련된 작업과 관련이 있다. 이것은 이 장의 뒷 부분에서 좀 더 자세히 논의 하게될 아래 4가지 기본 요소로 구분될 수 있다.

 

 - TV화면에서 표현되는 UI 도구(widget) 집합

 - 디스플레이의 다른 요소들을 조작하기 위한 클라스(class)들과, 디스플레이 스텍(stack)을 모델링하기 위한 클라스(class)들

 - 다른 어플리케이션간에 자원을 공유하는 문제와 관련된 클라스(class)들

 - 리모콘을 지원하기 위한 사용자 입력 관련 요소들의 확장

 

 

The Display Model in a DTV Receiver(DTV수신기에서의 디스플레이 모델)

다른 부분에서의 변화를 살펴 보기 전에, MHP나 OCAP 시스템에서 그래픽 모델이 어떻게 작동되는지에 대한 이해가 필요하다. 이것은 연산 능력이 부족해서 모든 것을 소프트웨어 적으로만 처리 할 수 없기 때문에, PC 환경에서 사용되는 것과 조금 틀리다. 이러한 문제 때문에 하드웨어가 수행하는 역활의 능력이 그래픽 모델이 구조에 있어 중요한 요소가 되는 것이다.

 

DTV 수신기의 디스플레이는 3개의 논리적인 층으로 구분될 수 있다. 뒤에서 부터 앞의 순서로, 백그라운드 층(background layer), 비디오 층(video layer), 그래픽 층(graphics layer)가 그것이다.

 

백그라운드 층(background layer)는 화면의 가장 뒤에서 간단한 색을 나타내고, 비디오가 보여지지 않은 영역을 채울 수 있다(예를 들면, 비디오 화면이 축소되어 화면의 일부만 차지하고 있을 때). 운이 좋은 경우에는, 많은 제약이 있긴 하지만, 이 층에다 이미지 같은 것을 나타낼 수도 있다.(아래에서 살펴 본다.)

 

그 다음 비디오 층은, 그 이름에서 알 수 있듯이, 비디오 화면이 나타나는 층이다. MHP나 OCAP에서는 비디오가 전체 화면에 나타날 수 있어야 한다는 말과, 화면을 1/4등분 했을 때, 4개중의 어떤 위치에서도 1/4로 축소된 화면을 나타낼 수 있어야 한다는 언급만 있기 때문에, 비디오가 전체 화면을 다 덮지 않을 수도 있다. 그러나, 몇몇 고성능의 수신기에서는 임의의 비율로 비디오를 축소 시킬 수도 있고, 임의의 위치에 비디오를 위치 시킬 수도 있다.

 

디스플레이스 스택(stack)의 가장 위에 층은, 그래픽 층이다. 이 층에는 어플리케이션이 사용하고자 하는 AWT 도구(widget)등을 포함하고 있다. 일반적인 수신기의 특성으로 인해, 이 그래픽 층이 화려할 것이라고 기대할 수는 없다. MHP 수신기는 720x576 해상도를 지원하도록 요구되고 있고, OCAP은 640x480을 최소한 지원하도록 되어 있다. 두 표준 모두 컬러는 256칼러를 최소한의 요구 사항으로 되어 있다. 그러나 이것은 말 그대로 '최소한' 지원해야 하는 사양이다. 더 높은 해상도나 더 많은 컬러를 지원하는 수신기도 있다. 그렇지만, 이러한 지원은 그 자체의 문제를 야기 시킨다. 높은 해상도를 지원하는 그래픽 층은 비디오 층에 직접적으로 대응시킬 수 없기 때문이다.

 

어떤 수신기에는 실제로 두개 이상의 그래픽 층을 만들기도 한다. 이것은 커서를 위한 층을 분리 시키기도 하고, 그래픽 층이 두개가 되고, 각 층간에 적당한 투명도를 두기도 한다. MHP나 OCAP 개발자들에게 이것은 큰 문제가 되지 않는다. MHP나 OCAP 미들웨어는 어디까지나 하나의 논리적인 그래픽 층을 가지고, 이러한 형태는 하드웨어 기저와 어떻게 대응시키느냐에 따른 미들웨어의 선택뿐이기 때문이다. 그림 7.3은 MHP의 디스플레이 스택(stack)의 다양한 장치들을 보여준다.

 

 

그림 7.3 MHP 디스플레이 스택(stack)의 장치들

 

 

 

이러한 층은 각각 구분된 형태로 구성되고, 거기에서 표현되어질 컨텐츠들 역시, 완전히 분리된 하드웨어에서 생산된다고 할 수 있다. 그러나 실제적으로는, 둘 또는 그 이상의 층들은 서로 상호 의존하는 형태라 할 수 있다. DTV 수신기에 대한 비용의 압력은 일반적으로 하나의 구성요소가 가능하면, 하나 이상의 임무를 수행하여 한다는 것을 의미하고, 이것은 수신기 전체의 성능에 영향을 미칠 수 밖에 없다. 이러한 차이점들은 하드웨어에 의존적이기 때문에, 각각의 플랫폼에서 동일하다고 가정할 수 없다.

 

이 곳에서 알 수 있는 사항은 간단하게 단 하나 이다. : 꼭 해야만 할 때만 그래픽 구성의 부분들을 변화 시켜야 한다. 어플리케이션은 그래픽과 비디오 구성 요소들을 다룰 때 유연성을 가져야 하고, 필요한 것을 항상 얻을 수 없을지도 모른다. 동시에, 필요할 때가 아니면 이미 동작하고 있는 어플리케이션을 왜곡해서도 안된다.

 

이러한 층들은 논리적으로 이와 같이 구성되어 있지만, 각각의 하드웨어 플랫폼은 이러한 층을 표현하기 위해서 각각의 하드웨어를 지원한다. 고사양의 플랫폼은 비디오 디코딩을 소프트웨어로 디코딩(decoding)할 것이고, 예를 들면, 하나의 물리적인 층에서 백그라운드, 비디오, 그래픽 층을 구성할 것이다. 어떤 플랫폼은 그래픽 층을 더 잘 지원할지도 모르고, 또는 비디오 층을 더 잘 지원할지도 모른다. 다만, 각각의 경우에서 이러한 층들의 논리적 구성은 여기서 논의 했던것 처럼 구성된다.

 

HScreens and HScreenDevices(HScreen 과 HScreenDevice)

디스플레이 장치의 구성과, 그것의 능력치를 찾아 내는 등의 문제를 해결하기 위해서, HAVi는

디스플레이 스택(stack)의 다양한 부분을 형상화 하는 많은 클라스(class)들을 정의 하였다.  이것의 첫번째가 바로 HScreen 클라스(class)이다. 이것은 물리적인 디스플레이 장치를 표현하고, 모든 MHP나 OCAP 수신기는 모든 물리적인 디스플레이 장치에 연결되는 하나의 HScreen 인스턴스(instance)를 가진다. 대부분의 경우에 수신기는 한번에 단지 하나의 HScreen 객체만 활성화 된다.

 

모든 HScreen은 그것이 속해 있는 여러개의 HScreenDevice 객체를 가진다. 이것들은 디스플레이와 관련된 다양한 층들을 표현한다. HScreenDevice는 단지 베이스 클라스(base class)일 뿐이고, 아래에 나타나 있는, 이것의 서브클라스(subclass)들에 더 관심을 기울여야 한다.

 

 - 백그라운드 층(background layer)를 나타내는 HBackgroundDevice

 - 비디오 층(video layer)를 나타내는 HVideoDevice

 - 그래픽 층(graphics layer)를 나타내는 HGraphicsDevice

 - 각각의 '실제' 구성요소가 흉내내고 있는 그래픽 장치를 나타내는 HEmulatedGraphicsDevice

 

HScreen 객체의 각 인스턴스(instance)는 적어도 하나의 HVideoDevice 인스턴스(instance)와, 적어도 하나의 HGraphicsDevice 인스턴스(instance), 그리고 (MHP 수신기라면) 하나의 HBackgroundDevice 인스턴스(instance)와 연관이 있을 것이다. 아래 HScreen 클라스(class)의 정의에서 보듯이, HScreen 객체의 적당한 메소드(method)를 호출함으로써, 해당 HScreen 인스턴스(instance)와 연관되어진 장치들의 참조를 얻을 수 있다.

 

   public class HScreen {

      public static HScreen[] getHScreens();

      public static HScreen getDefaultHScreen();

 

      public HVideoDevice[] getHVideoDevices();

      public HGraphicDevice[] getHGraphicsDevices();

 

      public HVideoDevice getDefaultHVideoDevice();

      public HGraphicsDevice getDefaultHGraphicsDevice();

      public HBackgroundDevice getDefaultHBackgroundDevice();

 

      public HScreenConfiguration[] getCoherentScreenConfigurations();

      public boolean setCoherentScreenConfigrations( HScreenConfiguration[] hsca);

   }

 

각 HScreen에 대해서, 3개의 장치에 기본 인스턴스(instance)의 참조를 얻을 수 있다. 이 메소드(method)들에 의해서 반환되는 인스턴스(instance)들은 일반적으로, '범용(general-purpose)' 그래픽 평면, 또는 주요 비디오 평면과 같은, 해당 HScreen의 '범용(general-purpose)' 장치들이다. 백그라운드 장치의 경우, 단지 하나의 백그라운드 장치만 가질 수 있기 때문에, 우리가 얻는 기본 장치는 하나일 것이다. 

 

HBackgroundDevice의 지원은 OCAP에서 선택사항이기 때문에, 백그라운드 층을 사용하고자 하는 OCAP 어플리케이션은 사용하기 전에 반드시 이것의 존재를 확인해야 한다. 그렇지 않고, 어플리케이션이 실제로는 존재 하지 않은 HBackgroundDevice를 가정하고 만들어 졌다면, 사용자는 추하게 결함있는 화면을 보게될 것이다. OCAP 수신기에서 백그라운드 장치가 장착되어 있지 않을 경우, getDefaultHBackgroundDevice() 메소드(method)는 null 값을 반환할 것이다.

 

비디오와 그래픽 층에 대해서, 각각 복수의 HVideoDevice나, HGraphicsDevice 인스턴스(instance)를 얻을 수도 있다. 수신기가 두개의 튜너와 두개의 MPEG 디코더(예를 들어, 다중화면을 지원하는 경우처럼)를 가지고 있다면, 우리는 두개의 비디오 장치를 가질 것이고, 비슷하게, 어떤 수신기에서는 여러개의 그래픽 장치를 가질 수도 있다. 그림 7.4에서는 MHP나 OCAP 수신기에서의 HScreenDevices 사용과 관련된 내용을 나타내었다.

 

 

 

그림 7.4 MHP/OCAP 수신기에서의 HScreenDevices

 

 

 

 

Configuring Screen Devices(스크린 장치의 구성)

일단 장치의 참조를 가져오고 나면, 필요한 특정 선택을 설정하기 위해 그것의 구성을 변경시켜야 할 필요성이 있을것이다. 또는, 어떤 특정 구성상태를 지원하는가 알기 위하여 장치에게 확인해 볼 필요성이 있거나, 우리가 원하는 구성 상태에 얼마나 가까운 상태로 얻을 수 있는지 확인해 볼 필요성이 있을지도 모른다. 이러한 경우 모두, 장치의 각 형태에 속해 있는 구성 클라스(configuration class)를 사용한다.

 

각 스크린 장치 클라스(class)는 관련된 구성 클라스(configuration class)를 가지고 있다. 그 이름은 적용하고자 하는 장치에 대응되는데, 예를들면, HVideoDevice 클라스의 구성 클라스(configuration class)는 HVideoConfiguration 클라스(class), HGraphicDevices는 HGraphicsConfiguration 클라스(class), 그리고 HBackroundDevice는 HBackgroundConfiguration 클라스(class)를 사용하여 구성한다. 이 모든 클라스(class)들은 HScreenConfiguration을 베이스 클라스(base class)로 하는 서브 클라스(subclass)들이다.

 

이러한 클라스(class)들은 픽셀 구성 비율이나, 해상도 같이 각 장치의 특정한 설정을 위해서 인자값을 통해 설정한다. 만약 Java 2 플랫폼에 익숙한 사람이라면, 이것 또한 비슷하게 느낄 것이다. Java 2 역시 그래픽 장치나, 그래픽 장치 구성을 위해서 유사한 방법을 사용한다. 이러한 유사점은 우연이라고 할 수 없다. 무엇 보다도, 이미 완벽하게 좋은 어떤것이 존재하면, 새롭게 다시 발명하지 않는다는 점을 상기하자. 그러나 이러한 유사점은 지금까지 유지되고 있지만, Java 2 플랫폼에서 구성 클라스(configuration class)들은 디스플레이 장치의 다른 구성을(해상도나 컬러 수와 같은) 나타낸다. DTV 수신기에서는 이러한 구성은 조금더 복잡한데, 디스플레이의 다양한 층과 상호 작용을 해야 하기 때문에 그렇다. 이러한 이유 때문에 우리는 새로운 구성 객체를 가져오는 작업 없이, 구성의 설정을 수정하는 형태로 사용할 수 있다.

 

각 구성들은 여러개의 인자값으로 정의되고, 어플리케이션은 HScreenConfigTemplate 클라스(class)의 적당한 서브 클라스(subclass)들을 이용하여 장치에 대한 인자값들을 정의할 수 있다. HScreenConfiguration 클라스(class)처럼 템플릿 클라스(class)들도 HScreenDevice의 모든 형태에 대한 서브 클라스(subclass)들이 존재 한다. 다양한 클라스(class)들 사이의 관계는 표 7.1에 나타나 있다.

 

표 7.1 스크린 장치와 거기에 속해 있는 구성 클라스(configuration class)와 구성 템플릿 클라스(configuration template class)

스크린 장치 (Screen Device)	구성 클라스 (Configuration class)	구성 템플릿 (Configuration template)
HBackground Device	HBackgroundConfiguration HStillImageBackgroundConfiguration	HBackgroundConfigTemplate
HGraphicsDevice	HGraphicsConfiguration	HGraphicsConfigTemplate
HEmulatedGraphicsDevice	HEmulatedGraphicsConfiguration
HVideoDevice	HVideoConfiguration	HVideoConfigTemplate

 

HBackgroundDevice는 두개의 분리된 구성 클라스(configuration class)를 가진다. HBackgroundConfigration은 단일 색으로 설정된 백그라운드의 구성을 정의하고 있다. 백그라운드 층에 어떤 이미지 형태를 보여주고 싶을 때는 HStillImageBackgroundConfiguration을 대신 사용해야 한다. 이것은 HBackgroundConfiguration의 서브 클라스(sub class)이기 때문에, 보통의 HBackgroundConfiguration이 사용될 수 있는 어디에서나 사용될 수 있다.

 

해당 장치의 적당한 구성을 찾아내는 방법에는 여러가지가 있다. 각 스크린 장치 클라스(class)에는 getDefaultConfiguration() 이라는 메소드(method)가 있어서, 그 장치의 기본 구성을 반환한다. 만약 다른 구성을 사용하고 싶을 때는, getConfigurations() 메소드(method)를 이용하면, 해당 장치가 지원하는 모든 형태의 구성들을 반환한다. 모든 구성에 대해서, 해당 구성과 대응되는 장치의 설정을 찾기위해 getConfigTemplate() 메소드(method)를 사용할 수 있다. 각 구성 클라스(configuration class)에 대해서, 이것은 대응되는 HScreenConfigTemplate의 서브 클라스(subclass)의 인스턴스(instance)를 반환할 것이다. 대응되는 템플릿 클라스(template class)는 표 7.1에 나타나 있다.

 

HScreenConfigTemplate을 생성하는 또 다른 방법은 우리가 설정하고자 하는 구성과 일치 시키고, 미들웨어가 얼마나 이것과 가까운 구성을 하는지 확인하는 방법이다. 스크린은 공유되는 자원이기 때문에, 장치의 구성을 변경하고자 하는 어플리케이션이 여러게 있을 수 있으며, 이 때문에 어플리케이션이 원하는 장치 구성과 가장 가까운 최선의 구성을 얻기 위해서 이러한 과정을 관리할 필요가 있다.

 

구성 템플릿(configuration template)을 일단 얻고 나면, 장치에 대한 설정을 변경시키기 위해서 이것을 사용할 수 있다. 각 구성 템플릿(configuration template)은 설정되어야 하는 여러개의 인자값들이 있고, 이러한 인자 값은 실제 장치 셋팅에 입력되게 되는 것이다. 다양한 그래픽 층들간의 상호작용으로 인해, 시스템의 다른 부분이나, 이미 동작하고 있는 어플리케이션에 대한 충분한 고민 없이 이 값들을 바로 설정할 수는 없다. 스크린 장치에 새로운 구성을 적용하려 할 때는, 이러한 인자값들을 적용하려고 하는 구성에 적용하는 일종의 제약조건들로 생각하는 것이 가장 좋다. 어플리케이션은 미들웨어에게 어떤 제약 조건들을 적용하려 한다고 말하고, 미들웨어는 다른 어플리케이션이나 미들웨어, 또는 하드웨어 자체에서 이미 적용한 다른 제약 조건들을 침범하지 않는 범위내에서 이러한 제약 조건들을 적용시키기 위해서 나름의 최선을 다 한다.

 

설정될 수 있는 각 인자들은 HScreenConfigTemplate이나 이것의 서브 클라스(subclass)중 하나에 상수로 표현되어 진다. 표 7.2는 각 스크린 장치들에 대해서 어떤 인자들이 설정되어 질 수 있는가를 나타내었다.

 

표 7.2 구성 인자값(configuration parameters)들과 적용되는 장치들

인자(Parameter)	HBackgroundDevice	HGraphicsDevice	HVideoDevice
PIXEL_ASPECT_RATIO	P	P	P
PIXEL_RESOLUTION	P	P	P
INTERLACED_DISPLAY	P	P	P
FLICKER_FILTERING	P	P	P
VIDEO_GRAPHICS_PIXEL_ALIGNED		P	P
SCREEN_RECTANGLE	P	P	P
ZERO_BACKGROUND_IMPACT	P	P	P
ZERO_GRAPHICS_IMPACT	P	P	P
ZERO_VIDEO_IMPACT	P	P	P
CHANGEABLE_SINGLE_COLOR	P
STILL_IMAGE	P
IMAGE_SCALING_SUPPORT		P
MATTE_SUPPORT		P
VIDEO_MIXING		P
GRAPHICS_MIXING			P

 

우리는 여기서 몇몇 인자값들을 살펴볼 것인데, ZERO_BACKGROUND_IMPACT, GRAPHICS_IMPACT, ZERO_VIDEO_IMPACT 값들은 이미 동작하고 있는 어플리케이션의 그래픽이나, 재생되고 있는 비디오에 어떠한 영향도 주지 않는 형태의 구성을 만들 때 사용된다. 이것은 어플리케이션이 매우 공손하거나, 다른 어플리케이션에 왜곡을 주지 않고자 할 때 사용된다.

 

VIDEO_GRAPHICS_PIXEL_ALIGNED은 비디오와 그래픽 층이 완벽하게 일치되는 형태를 가르킨다(예들들어 비디오 위에 그래픽들이 픽셀에 완벽하게 일치되는 형태로 겹쳐질 때). 이것은 어플리케이션이 비디오의 특정 부분에 겹쳐지고자 할 때 유용하다. 예를 들어, 퀴즈쇼가 현재의 문제(그리고 답)를 비디오 스트림의 한 부분으로 화면위에 보여지지만, 이 프로그램과 관련있는 어플리케이션이 사용자가 집에서 직접 즐기게 하기 위해서 그것의 그래픽을 그 위에 놓아 둘 경우에 유용한 것이다.

 

지금까지는 설정 가능한 인자들에 대해서 살펴 보았는데, 지금부터는 그것을 어떻게 설정하는가에 대해서 자세히 살펴 보자. 각 인자들은 두 부분으로 되어 있다. : 희망했던 값들과 우선순위. 희망하는 값은 스스로 설명하는 형태이고, 이 값의 형태는 설정하고자 하는 인자값에 의존한다. 우선순위는 미들웨어에게 특정한 설정이 어플리케이션에게 얼마나 중요한지에 대해서 설명한다. 이것에 대한 설명은 표 7.3에 약술하였다.

 

표 7.3 장치 구성 인자값들의 우선순위

우선순위(Priority)	의미
REQUIRED	이 선택은 꼭 적용되어야 한다.
PREFERRED	이 선택은 적용되어져야 하지만, 필요한 경우 무시할 수 있다.
UNECESSARY	어플리케이션은 이 선택에 대한 값을 선호하지 않는다.
PREFERRED_NOT	이 선택은 적용되어지지 않아야 하지만 필요하면 적용할 수 있다.
REQUIRED_NOT	이 선택은 적용되어져서는 안된다.

 

이것은 어플리케이션에게 원하는 특정 구성에 대한 합리적인 자유도를 부여하고, 동시에 수신기는 어플리케이션의 요구 사항과, 다른 어플리케이션들의 요구 사항, 그리고 다른 스크린 장치에 노출되어 있는 제약사항등을 일치 시키는데 유연성을 발휘할 수 있게 한다.

 

일단 HScreenConfigTemplate의 적당한 서브 클라스(subclass)의 인스턴스(instance)를 생성하고, 원하는 구성에 일치시키기 위한 인자값들을 설정하고 나면, 우리가 구성하고자 하는 스크린 장치가 실제로 그 구성을 지원하는지 확인할 수 있다.  HScreenDevice의 각 서브 클라스(subclass)들은 getBestConfiguration() 이라는 메소드(method)를 가지고 있는데, 이것은 일치하는 HScreenConfigTemplate 클라스(class)의 서브 클라스(subclass)들을 인자로 받는다.

 

어플리케이션이 이 메소드(method)를 호출하면, 미들웨어는 구성 템플릿(configuration template)의 선택사항들을 확인하고, 유요한 구성으로 만들기 위한 시도를 한다. 가장 적당한 구성은 아래와 같은 방법으로 일치 시킨다.

 

 - REQUIRED로 특정된 모든 인자값

 - REQUIRED_NOT으로 특정된 모든 인자값 제외

 - PREFERRED로 특정된 인자값들은 가능한 많이 포함

 - PREFERRED_NOT으로 특정된 인자값들은 가능한 많이 제외

 

미들웨어가 REQUIRED 또는 REQUIRED_NOT 로 되어 있는 인자값들을 모두 만족시키지 못하면, getBestConfiguration() 메소드(method)는 null 값을 반환한다. 그렇지 않으면 우리가 요구한 것에 가장 일치되는 구성의 참조를 리턴할 것이다.

 

이 메소드(method)의 변형은 구성 템플릿(configuration template)의 배열을 받아 들이기도 한다. 이 경우에, 미들웨어는 모든 템플릿(template)이 특정하는 제약조건들을 살펴 보고, 그것들에 가장 가까운 형태의 구성을 단 하나 반환한다. REQUIRED, REQUIRED_NOT으로 되어 있는 인자를 모두 만족시킬 수 없는 경우, 역시 null 참조를 반환할 것이다. 이 메소드는 어플리케이션이 아주 정중한 방법으로 적용하고자 하는 구성들에 가장 적합한 하나의 구성을 찾게 해주고, 구성 자체를 너무 자주 바꾸지 않는 범위내에서 적당히 양보하거나 타협할 수 있는 방법을 제시 한다.

 

앞서 살펴 보았듯이, 알맞은 구성을 선택하는 것은 많은 제약 조건을 구체화 하기 위한 훈련이 필요할 수도 있는데, 이것은 꼭 그래픽 계층의 상호 작용에 기인한것 만은 아니다. 시스템의 다양한 장치들의 능력과 결함된 다른 어플리케이션이 새로운 구성에 꼭 적용시켜야 하는 다양한 인자값들 때문이라 할 수 있다. 미들웨어는 우리의 템플릿(template)이 제공하는 제약조건과 일치되는 새로운 HScreenConfigTemplate을 만들어내기 위해서 이러한 조건들에 대한 해결책을 찾아내야 한다.

 

예를 들어, 어플리케이션이 ZERO_GRAPHICS_IMPACT 인자값을 REQUIRED로 설정하였다고 가정하자, 다른 어플리케이션이 VIDEO_GRAPHICS_PIXEL_ALIGNED 인자값을 역시 REQUIRED로 설정하면, 수신기는 비디오 장치를 그래픽 장치와 일치시키도록 변경하는 방법이로, 이 두 조건 모두를 만족시킬 수 있다. 만약 비디오 장치가 현재 그래픽 구성의 해상도나 픽셀 구성 비율을 동일하게 하는 것을 지원하지 않는다면, 이러한 요구 사항에 일치 시키는 구성을 정의 하는 것이 가능하지 않을 것이다. 이러한 경우에는 어플리케이션이 시도했던 구성 템플릿(configuration template)은 null 참조 값을 반환할 것이다.

 

그래픽 장치에 대해서는, 어플리케이션이 이러한 제약 조건을 다른 방법으로 선택할 수 있다. 어떤 경우에는, 미들웨어는 장치에 대한 다른 '실제' 구성을 사용하고 있는 동안에 사용자가 원하는 구성을 모방할 수 있다. 예를 들면, 수신기는 16:9 화면에서 4:3의 비율의 화면을 흉내내는 것이 가능하다. 이렇게 흉내내는 그래픽 장치들은 HGraphicDevice의 서브클라스(subclass)인 EmulatedGraphicsDevice 클라스(class)의 인스턴스(instance) 형태가 된다. 흉내내어 지는 그래픽 장치는 실제 그래픽 장치를 사용하는 것 보다 훨씬 느린 속도를 나타내겠지만, 어플리케이션의 입장에서는 별다른 차이점을 느낄 수 없다.

 

HEmulatedGraphicsDevice는 HEmulatedGraphicsConfiguration을 일반적인 HGraphicsConfiguration 대신 사용한다. 이것은 HGraphicsConfiguration에서 얻을 수 있는 모든 정보를 역시 받을 수 있지만, 수신기가 흉내내는 작업에 필요한 실제 장치와 흉내내는 장치 사이의 일치를 위한 정보를 나타낼 수 있게 확장되었다. 어플리케이션은 HEmulatedGraphicsDevice의 getImplementation() 메소드(method)의 호출을 통해서 그래픽 장치 기저의 구성을 나타내는 HGraphicsConfigTemplate 객체를 얻을 수 있다. 어플리케이션은 이것을 통해서 실제 장치와 흉내내어진 장치를 비교할 수도 있고, 필요한 경우 성능을 최적화 시키기 위한 기타 작업들을 수행할 수도 있다.

 

하나의 실제 그래픽 장치는 하드웨어 지원의 여하에 따라서, 동시에 여러개의 HEmulatedGraphicsDevices를 흉내낼 수 있다. 물론 많은 흉내내는 구성을 사용하면 성능의 저하가 크게 일어나기 때문에, 미들웨어을 만들 때, 이러한 흉내내어지는 장치에 대한 지원 요소에 대해서 많은 고민을 해야 한다. 많은 흉내내는 장치를 구현한다는 것이 항상 좋은 것만은 아니다.

 

설계자나 어플리케이션 개발자들이 어플리케이션의 UI를 만들 때 확실히 해야 하는 기본적인 가정은, MHP와 OCAP은 수신기의 다양한 장치들에 대해서 최소한의 해상도를 특정한다는 것이다. MHP수신기가 지원하는 최소한 지원되는 해상도에 대해서 표 7.4에 나타내었다.

 

 

표 7.4 MHP 수신기의 최소 장치 해상도

장치(Device)	수평 해상도	수직 해상도
백그라운드(Background)	720	576
비디오(Video)	720	576
그래픽(Graphics)	720	576

 

이러한 가정은 PAL화면이라는 것이고, 각 수신기는 각 형태에 최소한 하나는 전체 화면에 대한 제어 능력을 가지고 있다고 생각하는 것이다. 백그라운드 장치의 경우는 해당 형태의 단 하나의 장치만 존재 한다.

 

그래픽 층은 정사각형 형태가 아닌 픽셀에 대한 지원이 요구된다. MHP 수신기는 768x576(4:3 화면) 해상도와 1024x576(16:9 화면) 해상도의 정사각형 형태의 픽셀을 선택적으로 지원한다. 수신기는 또한, 4:9과 16:9의 화면에서 수용하능한 출력을 제공하기 위해 14:9 비율 형태인 흉내내는 그래픽 장치에 대한 지원이 필요하기도 하다.

 

실제적으로는 이러한 화면 비율에 대한 전환이 이미지를 처리 하는데 있어서 큰 도움은 되지 않는다. 그러나, 픽셀 대 포인트 비율은 MHP에서 텍스트에 대해서는 다른 비율로 정의하고 있기 때문에, 14:9를 사용한다는 것은 텍스트에 대해서는 16:9와 4:3 화면에서 모두 같은 픽셀만큼의 가로 길이를 가진다는 것을 의미한다. 이것은 그패픽 구성을 방해 하지 않고 텍스트를 레더링 할 수 있다는 의미이기 때문에, 디자인시에 유용한 편법으로 활용될 수도 있다. 텍스트의 가로 길이가 화면 비율에 상관없이 일정하기 때문에 디자이너들의 작업이 훨씬 편해 질 수 있는 것이다. OCAP에서는 주로 미국 시장에 대한 고려가 강하기 때문에, NTSC 표준을 따른다. OCAP 수신기가 따라야 할 최소한의 해상도는 표 7.5에 나타나 있다.

 

표 7.5 OCAP 수신기의 최소 장치 해상도

장치(Device)	수평 해상도	수직 해상도
백그라운드(Background)	640	480
비디오(Video)	640	480
그래픽(Graphics)	640	480

 

OCAP의 I11 버전 부터, 고화질 비디오 출력을 지원하는 수신기는 960x540의 그래픽 해상도를 지원해야 한다. MHP와 달리, OCAP은 이러한 해상도는 정사각형 형태의 픽셀을 근간으로 해야 한다고 명시되어 있기 때문에, OCAP개발자가 픽셀 비율에 대해서 걱정할 필요는 없다. 그러나 OCAP 수신기도 16:9와, 4:3 화면 비율을 모두 지원해야 한다.

 

OCAP 수신기는 선택적으로, 1280x720(16:9 정사각 필셀 형태의 full screen)이나, 704x480(정사각 픽셀 형태가 아니느 4:3 full screen)과 같은, 그래픽 장치의 다른 해상도를 지원할 수 있지만, 640x480의 해상도는 의무적으로 지원하여야 한다. OCAP 수신기는 또한 흉내내는 그래픽 장치들을 꼭 지원할 필요는 없다. 어플리케이션은 java.awt.Toolkit.getScreenSize() 메소드(method)를 통해서 그래픽 장치의 화면 크기에 대한 정보를 얻어올 수 있다. 이것은 기본 그래픽 장치의 현재 구성에 대한 픽셀 해상도를 반환할 것이다. 이러한 구성은 언제든지 바뀌어 질 수 있기 때문에, 이 메소드(method)의 반환값도 언제나 바뀔 수 있다. 이미 살펴본 바와 같이, OCAP 수신기에서는 HBackgroundDevice에 대한 지원 역시 선택사항이기 때문에, 어플리케이션은 HBackgroundDevice를 지원하는지 여부에 대해서 사용하기 전에 꼭 확인해보아야 한다.

 

Screen Devices and Resource Management(화면 장치와, 자원 관리)

화면 장치는 희귀 자원(scarce resource)이기 때문에 어플리케이션이 사용하기 위해서는 그 구성을 변경시킬 수 있는 권리를 확보해야 한다. 바로 다음 어플리케이션이 구성을 변경시킬려고 할 때 마다, 미들웨어는 이러한 변화가 시스템의 다른 스크린 장치의 구성과 호환성이 유지 되는지에 대해서 확인을 한다. 어플리케이션이 장치를 확보하지 못한 채로 구성을 설설정하려고 하면, 미들웨어는 HPermissionDeniedException을 던진다.

 

MHP와 OCAP의 다른 API들 처럼, HAVi의 자원 확보 모델은 이전 장에서 살펴 보았던, DAVIC의 resource notification API를 사용한다. 장치를 확보하기 위해서, 어플리케이션은 사용하고자 하는 스크린 장치의 인스턴스(instance)에서 HScreenDevice.reservieDevice() 메소드(method)를 호출하여야만 하고, org.davic.resources.ResourceClient를 implements한 클라스(class)를 인자값으로 넘긴다. 해당 장치를 확보한 어플리케이션이 없다면, 메소드(method)는 true를 반환하여 그 어플리케이션만 장치의 구성을 변경할 수 있도록 한다. 같은 스크린 장치에서 HScreenDevice.releaseDevice()를 호출함으로써, 다른 어플리케이션을 위해서 장치를 해제한다.

 

바람직한 민주 시민 처럼, 어플리케이션은 필요한 시간동안만 장치를 사용해야만 하며, 어쩔 수 없는 경우에만 구성을 설정하여야 하고, 절대 필요한 경우에만 장치를 확보해야 한다. 필요한 시간 보다 더 길게 장치를 확보하는 것은 다른 어플리케이션이 구성을 변경시키기 못하게 하고, 이것은 다른 어플리케이션에게 배타적일 가능성이 크기 때문에, 구성을 변경하지 않는 것이 치명적인 경우가 되지 않는다면, 최대한 피해야 한다. 지금 당장 어플리케이션이 어떻게 할 것이다라는 것을 예측하기는 힘들지만, 대부분의 경우에 어플리케이션은 구성의 설정이 끝나자 마자 이것을 해제 해야 한다.

 

불행하게도, 우리가 생각하는 것 만큼 이러한 사항들이 그리 단순하지는 않다. 이 장의 앞에서 디스플레이 스택(stack)의 여러 층들은 완벽하게 독립적인 형태가 아니라는 것을 언급했었다. 비용 절감의 압력으로 인해, 디스플레이 스택(stack)의 각 층사이에는 공유되는 하드웨어 요소들이 있을 수 있다. 이것은 어떤 스크린 장치의 구성을 변경하면, 다른 장치의 구성도 동시에 변경될 수 있다는 것을 의미한다.

 

이것의 가장 확실한 예는 백그라운드 층과 비디오 층이라 할 수 있다. 백그라운드 층의 스틸 이미지는 대부분 MPEG I-frame일 것이고, 이 이미지를 표현하기 위해서 수신기는 하드웨어 MPEG 디코더를 다시 사용한다. 그렇게 한다는 것은 백그라운드 이미지를 표시하기 하는 동안 비디오는 멈출것이고, 방송되는 비디오 스트림을 디코딩(decoding)하기 위해서 MPEG 디코더(decoder)를 사용하지 못한다는 의미일 수도 있다. 하드웨어 플랫폼(platform)에 따라서, I-frame을 표시하기 위해서 비디오에 조금의 흠집이 나는 정도일 수도 있고, 전체 비디오 재생에 방해가 될 수도 있다.

 

이것의 의미하는 바는, 우리가 어떤 장치의 구성을 변경시키면, 우리가 꼭 사용하여야 하는 다른 장치의 구성에 대한 변경을 야기 시킬 수 있다는 것이다. 어플리케이션이 어떤 장치를 구성하려 할 때, HPermissionDeniedExceptions을 받으면, 해당 장치가 이미 어플리케이션에서 확보하고 있는가를 살펴볼 필요가 있다. 이런 경우는 새롭게 적용하려는 구성이 다른 장치의 상황을 재구성할 필요를 만든다는 것이고, 필요한 장치에 대한 확보를 못할 수도 있다는 것을 의미한다. 재구성하고자 할 때, 같은 형태의 모든 장치를 확보한다거나(HGraphicDevice를 구성하면서, 모든 형태의 HGraphicDevice를 확보한다거나), 같은 하드웨어 기저를 사용하는 장치들을 확보함으로써(HVidoeDevice를 재구성 하려고 할 때, HBackgroundDevice로 함께 확보하는것 처럼) 이러한 문제를 해결할 수 있다.

 

실제로는, 필요로 하는 장지만 확보하는 것이 쉽지 않다. 다른 장치 사이에 종속적인 측면이 있다고 살펴보았지만, 각 플랫폼에 어떠한 종속적인 요소가 존재한다고 일반화시켜 이야기 할 수 있는 방법이 없다. 어플리케이션은 실제 미들웨어가 어떠하리라고 추측할 수 밖에 없으며, 이러한 종속성을 만족시킨다고 생각되는 최소한의 장치만을 확보하려고 노력하는 방법 밖에 없다.

 

A Practical Example of Device Configuration

이제 그래픽 장치를 확보하는 것으로 이러한 것이 어떻게 작동되는지 살펴 보자. HGraphicsDevice 클라스(class)는 아래와 같은 인터페이스(interface)를 가지고 있다.

 

   public class HGraphicsDevice extends HScreenDevice {

  

      public HGraphicsConfiguration[] getConfigurations();

 

      public HGraphicsConfiguration getDefaultConfiguration();

 

      public HGraphicsConfiguration getCurrentConfiguration();

 

      public boolean setGraphicsConfiguration(HGraphicsConfiguration hgc)

            throws SecurityException, HPermissionDeniedException, HConfigurationException;

 

      public HGraphicsConfiguration getBestConfiguration(HGraphicsConfigTemplate hgct);

 

      public HGraphicsConfiguration getBestConfiguration(HGraphicsConfigTemplate hgcta[]);

 

   }

 

이 메소드(method)들의 대부분은 이 장의 앞에서 이미 살펴보았기 때문에, 여기서 더 자세한 내용을 언급하지는 않겠다. setGraphicsConfiguration() 메소드(method)는 장치의 구성을 설정하게 하고, 여러 예외를 던지도록 되어 있다. 방송 사업자가 어떤 어플리케이션에게 스크린 장치의 구성을 변경할 수 있는 권한을 부여하지 않았으면, SecurityException을 던지고, 장치를 확보하지 못했거나, 해당 장치의 설정을 변경하는 것이 이미 이 장치를 확보하여 동작하고 있는 어플리케이션에 영향을 미치는 경우라면, HPermissionDeniedException을 던진다. 마지막으로 스크린 장치가 우리가 필요로 하는 기능을 제공하지 않는다면(예를 들어, 해당 configuration template으로 호출했을 때, getBestConfiguration()이 null을 리턴하였다면), HConfigurationException이 던져질 것이다. 지금까지 그래픽 장치의 인터페이스(interface)를 살펴 보았는데, 지금 부터는 그것을 어떻게 구성하는지에 대해서 살펴 보자. 아래 구성과 관련된 코드를 살펴보자

 

   // 첫 번째, 사용하고자 하는 HScreen 을 얻는다.

   // (이 경우 기본 장치를 가져온다.)

   HScreen screen = HScreen.getDefaultHScreen();

 

   // 이제 사용하고자 하는 HGraphicsDevice를 가져오자

   // (역시 기본 장치를 가져온다)

   HGraphicsDevice device;

   device = screen.getDefaultHGraphicsDevice();

 

   // 그래픽스 구성을 위한 새로운 템플릿(template)을 생성하고,

   // 선호하는 선택사항의 설정을 시작한다.

   HGraphicsConfigTemplate template;

   template = new HGraphicsConfigTemplate();

 

   template.setPreference(template.IMAGE_SCALING_SUPPORT, template.PREFERRED);

 

   template.setPreference(template.ZERO_VIDEO_IMPACT, template.REQUIRED);

 

   //우리의 선택 사항과 일치하는 장치 구성을 얻는다.

   HGraphicsConfiguration configuration;

   configuration = device.getBestConfiguration(template);

 

   // 마지막으로 실제 구성을 설정한다.

   // 이것을 하기 전에, 우리의 구성이 null이 아닌지를 확인한다.

   // (우리의 선택 사항이 실제로 유요한지 확인하기 위함이다.)

   if(configuration != null) {

      // 구성을 설정하기 전에 해당 장치를 확보해야만 하고,

      // 작업을 끝내자 마자 다시 해제하여야 한다.

      // 해당 장치를 확보하기 위해서 org.davic.resource.ResourceClient

      // 객체를 넘기는 것이 필요하다.

      device.reserveDevice(myResourceClient);

 

      // 이제 구성을 설정한다.

      try {

         device.setGraphicsConfiguration(configuration) ;

      }

      catch(HPermissionDeniedException hpde) {

         // 지금은 아무것도 안하는 것으로 하자

      }

      catch(HConfigurationException hce) {

         // 지금은 아무것도 안하는 것으로 하자

      }

 

      // 다른 어플리케이션에게 불편을 주지 않기 위해 가능한 빨리 장치를 해제 한다.

      device.releaseDevice();

   }