며칠을 고심 끝에, 찾아냈다고 해야하나 당연하다고 해야 하나...ㅡ,.ㅡa
이전 STB(셋탑박스)에 들어갈 미들웨어의 일부분이 될 application 인 SETUP 프로그램을 개발 중이었다.
TV STB인 관계로 프로그램을 시청하는 중에 "메뉴"버튼을 클릭하면 SETUP 메뉴가 나타나야 한다.
그러다 보니, SETUP 프로그램이 화면 전체를 가리지 않는 이상, SETUP 프로그램 뒤 배경에 영상이 나오게 된다.
디자인적인 미적 효과를 넣게 되면, 뒤 배경 영상 위로 알파값(alpha)을 적용해서 뿌옇게 처리한다던가 등의 왜곡(?)을 줄 수 있겠다.
그 알파값 적용을,
Color c = new Color(r,g,b,a);
g.setColor(c);
g.fillRect(x, y, width, height);
메소드를 통해 화면 구현을 했다.
이 내용을 더블버퍼링으로 변경하면,
Dimension d = getSize();
if ((offGraphics == null) || (d.width != offDimension.width) || (d.height != offDimension.height)) {
offDimension = d;
offImage = createImage(d.width, d.height);
offGraphics = offImage.getGraphics();
}
// (1) offGraphics.clearRect(0, 0, d.width, d.height);
// (2) 최초 배경색으로 채운다. 알파값 적용.
offGraphics.setColor(getBackground());
offGraphics.fillRect(0, 0, d.width, d.height);
// (3) 원하는 알파값을 채운다.
offGraphics.setColor(new java.awt.Color(255, 0, 0, 45));
offGraphics.fillRect(0, 0, 500, 100);
//화면 개체를 그린다.
paintUI(offGraphics);
//실제 화면에 출력한다.
if (offImage != null)
g.drawImage(offImage, 0, 0, null);
위와 같이 구현할 수 있다.
그런데, 알파값을 적용할 경우, 고려 사항이 있는데, 더블 버퍼링을 구현 함에 있어, 내부 버퍼에서 그림을 그리는 Graphics context를 초기화-clear- 를 하지 않으면, 실제 화면 출력시에 알파값 적용 부분이 처음부터 중첩이 되어 나타나게 된다. 즉, 알파값 적용 부분이 점점 진해져서 알파값 적용이 없어지게 된다.
이때에는, 필히 내부 버퍼의 Graphics context를 clear 해 주도록 하자.
위 코드에서 (1) 부분의 주석을 풀어주면 된다.
물론, 보이지않는 내부 버퍼이긴하나 영역 크기만큼 clear 시키는 거라 시간이 지연되긴 한다.
'IPTV'에 해당되는 글 4건
SIGMA8634 chipset 기반에서 시스템 전반에 관여하는 SETUP 프로그래밍을 하고 있다.
havi ui API를 이용하지 않고 java awt api 만을 이용하여 개발 중이다. jvm 호환성만 의존한 상태로 다양한 플랫폼을 지원하기 위해서이다.
SETUP UI 를 개발하면서 가장 큰 애로사항 또는 고려할 점은,
1. 사용자 액션-리모콘 입력-에 따라 즉시 화면이 출력되어야 하므로 빠른 반응을 위해서 SETUP UI 는 미리 메모리에 객체 생성/초기화 되어 있어야 한다.(객체, 리소스(이미지, 사운드 등))
2. STB 과 같은 제한된 자원의 임베디드 환경이라는 점.
3. 메뉴 간 이동(전환) 빠르기가 적절해야 한다.
4. UI 가 편리해야 한다.
..정도로 생각할 수 있겠다.
이 중에서 구현하는 데 있어 깊은(?) 내공을 가지지 않고서는 힘든 부분이 있는데-다른 부분도 마찬가지지만..ㅡ,.ㅡa- , 3번을 고심해 볼 필요가 있다.
예로, A 메뉴가 있고, A 메뉴 내 B 서브 메뉴가 있는 등,
- A
----- B
----------- E
----------- F
----------- G
----- C
----- D
위와 같이 가정하면,
A 메뉴 내에는 B, C, D 메뉴가,
B 메뉴 내에는 E, F, G 메뉴가 구성되어 있다는 것을 알 수 있다.
즉, A 메뉴에서 B 메뉴를 선택하면, 화면이 바뀌면서 전체 화면이 B 메뉴가 주관이 된다.
이때, 전체 A 메뉴에서 B 메뉴로 바뀔 때,
여럿 graphics api 를 이용하여 실시간으로 그림을 그릴 것인지, 미리 화면을 그려놓았다가 화면 전환을 할 것인지는 개발자 몫이다.
하드웨어 성능이 뒷받침이 된다면야 실시간도 무리가 아니지만 임베디드라는 환경에서, 보통은 화면 깜빡임이 나타나는데-큰 화면을 부분적으로 그리더라도, 빠른 PC에서 조차도 나타난다.- 이를 방지하고자 더블버퍼링 기술을 쓰기도 한다.
그래서, 고심 끝에 각 메뉴별 장면을 미리 그려놓았다가 메뉴 전환시 메뉴별 장면을 바꿔치는 방법을 선택했다.-자원 문제에 대해서 다음에 다룬다.-
이를 쉽게 응용할 수 있는 방법으로, awt CardLayout 있었다.
CardLayout 은 장면 전환이 쉽게 되도록 지원하는 배치 관리자 중 하나인데, 카드를 여러 개 포개어 놓고, 필요한 카드만 보는 레이아웃이다.
처음 개발 중에는 저 레이아웃을 이용해 각 장면 단위로 어떤 컴포넌트를 이용할까 고민하다가 고른 것이 Canvas 였다.
java에서 그림 그리기 딱인 컴포넌트가 Canvas 이니까 말이다.
그래서 각 장면을 Canvas를 상속받아 Scene 이란 컴포넌트를 만들게 되었고, 아래와 같이 각 장면 컴포넌트는 CardLayout 에 이용해 출력했다.
//장면 생성
//MainMenu와 SystemMenu는 Scene을 상속
MainMenu mainMenu = new MainMenu();
SystemMenu systemMenu = new SystemMenu();
.
.
//장면을 출력할 container
Frame frame = new Frame("Setup");
Window window = new Window(frame);
//레이아웃매니저
CardLayout cardLayout = new CardLayout();
window.setLayout(cardLayout);
//장면을 등록
window.add("MainMenu", mainMenu);
window.add("SystemMenu", systemMenu);
.
.
//원하는 장면 출력
cardLayout.show(window, "MainMenu");
.
.
cardLayout.show(window, "SystemMenu");
.
.
위와 같은 형태로 코딩했다. 그리고 테스트를 수행...
그런데 생각지 못한 결과가 나왔다.
장면 전환시 깜빡임이 발생했다. 미리 장면을 다 그려놓고 장면을 바꿔치기 한 것 뿐인데 화면 깜빡임이 발생한 것이다.
시간 차를 주고 디버깅을 해보니, 분명 장면을 그리는 중에 나타나는 현상을 아닌 것 같았는데 한참이나 고심을 했다.
그런데 아주 쉽게 풀리는 열쇠를 발견 했으니, 장면이 상속받은 개체에 문제가 있었다.
쉽게 그림그리는 장면 단위만 생각해서 Canvas 개체를 가져다 쓴 것인데, 이게 jvm 내에서 Canvas를 교체할 경우-장면전환- 화면을 다시 지우는 현상이 있었다.
Canvas에서 Container 로 변경하니 깜빡임이 없어졌다.
//변경 전
public abstract class Scene extends Canvas
//변경 후
public abstract class Scene extends Container
Container 를 상속받느냐 Canvas를 상속받느냐에 따른 화면 처리 차이가 궁금해진다.
둘다 Component에서 시작한 것들인데 CardLayout에서 화면 출력시 처리가 다른 모양이다.
언제 찾아보기나 할까나~ ^^;;
havi ui API를 이용하지 않고 java awt api 만을 이용하여 개발 중이다. jvm 호환성만 의존한 상태로 다양한 플랫폼을 지원하기 위해서이다.
SETUP UI 를 개발하면서 가장 큰 애로사항 또는 고려할 점은,
1. 사용자 액션-리모콘 입력-에 따라 즉시 화면이 출력되어야 하므로 빠른 반응을 위해서 SETUP UI 는 미리 메모리에 객체 생성/초기화 되어 있어야 한다.(객체, 리소스(이미지, 사운드 등))
2. STB 과 같은 제한된 자원의 임베디드 환경이라는 점.
3. 메뉴 간 이동(전환) 빠르기가 적절해야 한다.
4. UI 가 편리해야 한다.
..정도로 생각할 수 있겠다.
이 중에서 구현하는 데 있어 깊은(?) 내공을 가지지 않고서는 힘든 부분이 있는데-다른 부분도 마찬가지지만..ㅡ,.ㅡa- , 3번을 고심해 볼 필요가 있다.
예로, A 메뉴가 있고, A 메뉴 내 B 서브 메뉴가 있는 등,
- A
----- B
----------- E
----------- F
----------- G
----- C
----- D
위와 같이 가정하면,
A 메뉴 내에는 B, C, D 메뉴가,
B 메뉴 내에는 E, F, G 메뉴가 구성되어 있다는 것을 알 수 있다.
즉, A 메뉴에서 B 메뉴를 선택하면, 화면이 바뀌면서 전체 화면이 B 메뉴가 주관이 된다.
이때, 전체 A 메뉴에서 B 메뉴로 바뀔 때,
여럿 graphics api 를 이용하여 실시간으로 그림을 그릴 것인지, 미리 화면을 그려놓았다가 화면 전환을 할 것인지는 개발자 몫이다.
하드웨어 성능이 뒷받침이 된다면야 실시간도 무리가 아니지만 임베디드라는 환경에서, 보통은 화면 깜빡임이 나타나는데-큰 화면을 부분적으로 그리더라도, 빠른 PC에서 조차도 나타난다.- 이를 방지하고자 더블버퍼링 기술을 쓰기도 한다.
그래서, 고심 끝에 각 메뉴별 장면을 미리 그려놓았다가 메뉴 전환시 메뉴별 장면을 바꿔치는 방법을 선택했다.-자원 문제에 대해서 다음에 다룬다.-
이를 쉽게 응용할 수 있는 방법으로, awt CardLayout 있었다.
CardLayout 은 장면 전환이 쉽게 되도록 지원하는 배치 관리자 중 하나인데, 카드를 여러 개 포개어 놓고, 필요한 카드만 보는 레이아웃이다.
처음 개발 중에는 저 레이아웃을 이용해 각 장면 단위로 어떤 컴포넌트를 이용할까 고민하다가 고른 것이 Canvas 였다.
java에서 그림 그리기 딱인 컴포넌트가 Canvas 이니까 말이다.
그래서 각 장면을 Canvas를 상속받아 Scene 이란 컴포넌트를 만들게 되었고, 아래와 같이 각 장면 컴포넌트는 CardLayout 에 이용해 출력했다.
//장면 생성
//MainMenu와 SystemMenu는 Scene을 상속
MainMenu mainMenu = new MainMenu();
SystemMenu systemMenu = new SystemMenu();
.
.
//장면을 출력할 container
Frame frame = new Frame("Setup");
Window window = new Window(frame);
//레이아웃매니저
CardLayout cardLayout = new CardLayout();
window.setLayout(cardLayout);
//장면을 등록
window.add("MainMenu", mainMenu);
window.add("SystemMenu", systemMenu);
.
.
//원하는 장면 출력
cardLayout.show(window, "MainMenu");
.
.
cardLayout.show(window, "SystemMenu");
.
.
위와 같은 형태로 코딩했다. 그리고 테스트를 수행...
그런데 생각지 못한 결과가 나왔다.
장면 전환시 깜빡임이 발생했다. 미리 장면을 다 그려놓고 장면을 바꿔치기 한 것 뿐인데 화면 깜빡임이 발생한 것이다.
시간 차를 주고 디버깅을 해보니, 분명 장면을 그리는 중에 나타나는 현상을 아닌 것 같았는데 한참이나 고심을 했다.
그런데 아주 쉽게 풀리는 열쇠를 발견 했으니, 장면이 상속받은 개체에 문제가 있었다.
쉽게 그림그리는 장면 단위만 생각해서 Canvas 개체를 가져다 쓴 것인데, 이게 jvm 내에서 Canvas를 교체할 경우-장면전환- 화면을 다시 지우는 현상이 있었다.
Canvas에서 Container 로 변경하니 깜빡임이 없어졌다.
//변경 전
public abstract class Scene extends Canvas
//변경 후
public abstract class Scene extends Container
Container 를 상속받느냐 Canvas를 상속받느냐에 따른 화면 처리 차이가 궁금해진다.
둘다 Component에서 시작한 것들인데 CardLayout에서 화면 출력시 처리가 다른 모양이다.
언제 찾아보기나 할까나~ ^^;;
올초 회사에서 유럽에 서비스를 보여주기 위해 포럼에 다녀왔었다.
국외 시장은 눈에 보이는 것만도 분위기가 많이 다른 듯 한데, 국내에서는 정책 문제로 이러지도 저러지도 못하다 최근에야 그나마 가닥이 잡힌 듯 하다.
JAVA 개발자로 얼마되지 않은 경력에 올해 들어 IPTV 분야에 몸담게 되었다.
IP 기반의 TV 서비스라 언뜻 간단하게만 생각했었는데, 가장 밖 껍데기만 벗겨내고나니 신기술에 대한 심오함에 다시한번 놀란다. 기술적인 구현에 있어 하나둘 접근할 때마다 그 깊이는...*_*
IPTV가 무엇일까? - 향후 서비스 방향 - PAT - PMT - ...
최근 들어서는 DSI/DII/DDB, Object Carusel 를 구현해 봤는데, 나름 흥미로운 부분이 많이 생겼다. 네트워크에서, 채널로, 서비스로, Video와, Audio, Data를 함께 전송하는 모든 일련의 과정들...
그런데, 아쉬운 것은 국내 검색 사이트를 비롯하여 그 흔한 PAT 에 대한 정보조차도 시원스럽게 풀어놓은 데가 없다.
구현에 있어 PAT를 가장 처음 접할 적엔 예제 코드가 없을까 싶어 찾다보니 프랑스 사이트 쪽으로 넘어가더라...ㅡ,.ㅡa
아무래도 DVB 며 유럽에서의 진척이 발빨라서인지 관련 자료를 검색할 수 있었다.
국내 IPTV 관련 기술로는 분야가 넓지 못하다.
아직 시장이 오픈되지 않았고, 성공적인 레퍼런스도 없을 뿐더러 가능성만 기대치가 높지 결과물이 없는 시장일테니 말이다.
특정 연구기관 단체에서 주가 된 프로젝트가 진행될 뿐이지, 학교나 여타 부가 가치를 위한 연구가 눈에 들어나 보이지 않는다.
분명 첫 시장을 선점하기 위해 공개를 꺼리는 분위기가 아쉽게만 한데, IT "오픈" 마인드를 위시하여 좀더나은 발전을 위한 장이 마련되었으면 좋겠다.
해서...IPTV 관련 개발자들을 위한 커뮤니티를 만들어볼까 생각 중이다.
어떤 좋은 안이 없을까?
혹시라도 이 글을 보게되는 IPTV관련 개발자 분이 계시다면 좋은 의견 내주시고 함께 만들어 갔으면 좋겠습니다.
국외 시장은 눈에 보이는 것만도 분위기가 많이 다른 듯 한데, 국내에서는 정책 문제로 이러지도 저러지도 못하다 최근에야 그나마 가닥이 잡힌 듯 하다.
JAVA 개발자로 얼마되지 않은 경력에 올해 들어 IPTV 분야에 몸담게 되었다.
IP 기반의 TV 서비스라 언뜻 간단하게만 생각했었는데, 가장 밖 껍데기만 벗겨내고나니 신기술에 대한 심오함에 다시한번 놀란다. 기술적인 구현에 있어 하나둘 접근할 때마다 그 깊이는...*_*
IPTV가 무엇일까? - 향후 서비스 방향 - PAT - PMT - ...
최근 들어서는 DSI/DII/DDB, Object Carusel 를 구현해 봤는데, 나름 흥미로운 부분이 많이 생겼다. 네트워크에서, 채널로, 서비스로, Video와, Audio, Data를 함께 전송하는 모든 일련의 과정들...
그런데, 아쉬운 것은 국내 검색 사이트를 비롯하여 그 흔한 PAT 에 대한 정보조차도 시원스럽게 풀어놓은 데가 없다.
구현에 있어 PAT를 가장 처음 접할 적엔 예제 코드가 없을까 싶어 찾다보니 프랑스 사이트 쪽으로 넘어가더라...ㅡ,.ㅡa
아무래도 DVB 며 유럽에서의 진척이 발빨라서인지 관련 자료를 검색할 수 있었다.
국내 IPTV 관련 기술로는 분야가 넓지 못하다.
아직 시장이 오픈되지 않았고, 성공적인 레퍼런스도 없을 뿐더러 가능성만 기대치가 높지 결과물이 없는 시장일테니 말이다.
특정 연구기관 단체에서 주가 된 프로젝트가 진행될 뿐이지, 학교나 여타 부가 가치를 위한 연구가 눈에 들어나 보이지 않는다.
분명 첫 시장을 선점하기 위해 공개를 꺼리는 분위기가 아쉽게만 한데, IT "오픈" 마인드를 위시하여 좀더나은 발전을 위한 장이 마련되었으면 좋겠다.
해서...IPTV 관련 개발자들을 위한 커뮤니티를 만들어볼까 생각 중이다.
어떤 좋은 안이 없을까?
혹시라도 이 글을 보게되는 IPTV관련 개발자 분이 계시다면 좋은 의견 내주시고 함께 만들어 갔으면 좋겠습니다.
IT 업계만치 앞날을 점치기 어려운 곳도 없다.
하루가 다르게, 하룻밤 자고 나면, 눈만 뜨면 온 동네방네 신기술이 널부러져 있으니 IT 안에서도 부분별 업계 담당자들인 영업맨이나 개발자들은 정신이 없겠지.
또, 예기치 않게 관련 세미나나 협의회 한번 참석했다가는 내 속 깊은 곳에서 움찔움찔 거리는 무언가를 느끼기까지 한다.
'옆 동네에서는 벌써 저런 것까지 하고 있구나...'
요즘 유달리 관심을 두게 된 곳, 또 좀더 깊이를 더해갈 분야인 IP-TV에 대해 생각해 본다.
아날로그 세대에서 디지털 세대로 환경적인 변화가 시작된 것도 이제 세어보기 민망할 정도다.
언뜻 보기에는 차근차근 그 대세를 몰아가고 있는 '하나TV'를 눈으로 확인할 수 있고, 언론에서 디지털TV 관련기술 소개며 앞으로의 방향을 얘기에 몸서리를 칠 정도니.
헌데 현실은 그렇게 평평대로만은 아닌 데 말야.
IP-TV는 Internet Protocol TeleVision 줄임말이다.
이미 활용 방안이 끝없는 인터넷망을 이용하여 TV 서비스를 제공하자는 의도에서 시작했단다.
기존 TV서비스는 영상과 음성 정보를 제공하고, ISP쪽에서 서비스를 제공하고 사용자가 받아들이는-단순히 보는- 데서 끝났다면, IP-TV는 영상, 음성 정보에 데이터정보를 더해서 사용자가 단순히 받아들이는 입장이 아닌 서비스 제공자와 상호 의사 소통이 가능한 서비스가 된다.
TV를 보다가 드라마 속에 출연하는 연예인이 입고 있는 옷이 마음에 들어서 그 즉시 검색할 수 있고, 쇼핑몰로 연결(데이터 방송 정보)할 수 있는 때가 곧 오겠지? 참 좋다~
연예인처럼 꾸미는 걸 즐기는 연예인빠, 따라쟁이의 뽐뿌는 어쩌란 말인가? 유행을 따라가고, 유행이 바뀌는 사이클이 훨씬 줄어들고 하니 쇼핑문화 날로 발전할 텐데 그때도 의류업계 불황이라 그럴까? ^^;
최근엔, LCD TV 수요자가 진짜 많다. 어지간히 해선 전자제품 구입한다 치면 '디지털' 글자 안들어간 게 없다.
좁게만 봐도 과연 저런 서비스가 언제즘이면 가능할까? 1년? 2년? 3년?...
디지털방송을 위해서는 껍데기뿐인 현재의 디지털방송은 앞으로 해결할 과제가 많다.
새로운 방송 방식을 위한 데이터 전송 방식의 표준이며, 데이터 송수신을 담당할 장비도 생산해야 하고, 가장 핵심적인, 소비자들의 입맛을 땡길 킬러 어플리케이션 서비스 개발-예로 쇼핑 관련-이 관건이겠다.
우리나라 뭐 된다하면 누구나가 달라붙어서 잘하잖아?
