KR100712374B1 - 데이터 처리 장치 - Google Patents

Abstract

코어 프로그램 객체가 데이터 처리 태스크들을 수행하도록 동작할 수 있는 복수의 플러그-인 프로그램 객체들과 상호작용하여 그 객체들의 동작을 제어하며, 상기 코어 프로그램 객체와 각각의 데이터 처리 태스크간에 통신을 제공하는 데이터 처리 장치에 있어서: (i) 상기 코어 프로그램 객체와 상기 태스크를 수행하도록 동작할 수 있는 하드웨어 장치간에 상호작용하게 하는 동기 인터페이스; 및 (ii) 상기 코어 프로그램 객체와 상기 태스크를 수행하도록 동작할 수 있는 하드웨어 장치간에 상호작용을 허용하는 비동기 인터페이스를 포함하는 데이터 처리 장치를 개시한다.

데이터 처리 장치, 동기 인터페이스, 비동기 인터페이스, 동기/비동기 변환기

Description

데이터 처리 장치{Data processing}

도 1은 디지털 비디오 특수 효과 장치를 개략적으로 도시한 도면.

도 2는 도 1의 장치의 동작 소프트웨어의 편성을 도시한 도면.

도 3은 도 1의 장치에 대한 동작 소프트웨어의 편성을 좀 더 상세하게 도시한 도면.

도 4는 도 1의 장치에서 갱신된 효과 파라미터의 전파를 개략적으로 도시한 도면.

도 5는 도 1의 장치에서 리-렌더 커맨드(re-render command)의 전파를 개략적으로 도시한 도면.

도 6은 그래프 편집 윈도우 및 팔레트 윈도우를 개력적으로 도시한 도면.

도 7은 그래프 편집 동작을 개략적으로 도시한 도면.

도 8은 합성 효과 아이콘의 생성을 개략적으로 도시한 도면.

도 9는 합성 효과의 파일 구조를 개략적으로 도시한 도면.

도 10은 뷰어 윈도우를 개략적으로 도시한 도면.

도 11은 동작 소프트웨어의 초기 배열을 개략적으로 도시한 도면.

도 12는 이전에 제안된 효과 플러그-인을 개략적으로 도시한 도면.

도 13은 새로운 형태의 효과 플러그-인을 개략적으로 도시한 도면.

도 14는 도 13의 효과 플러그-인에 대한 프록시 효과 및 효과 서버 사이의 관계를 개략적으로 도시한 도면.

도 15는 시스템 캐시를 개략적으로 도시한 도면.

도 16은 플러그-인 인터페이스를 개략적으로 도시한 도면.

본 발명은 데이터 처리 방법 및 장치에 관한 것이다.

일부 컴퓨터 기반 데이터 처리 시스템들은 "코어(core)" 컴퓨터 프로그램과, 필요시 로드될 수 있는 다수의 실행가능한 프로그램 모듈들 혹은 "플러그-인(plug-in)"을 이용한다.

마이크로소프트 윈도우즈(등록상표) 운영체제의 다양한 용어를 사용하면, 프로그램 모듈 또는 플러그-인은 "동적 로드 라이브러리" 혹은 "DLL"로서 제공될 수 있다. 일반적으로 DLL은 프로그램 코드, 데이터 및 서브루틴 라이브러리를 포함할 수 있는 큰 파일이다. 이들은 현재의 프로그램 수행시 필요할 때 메모리에 로드된다.

이러한 형태의 구조가 유용할 수 있는 데이터 처리 시스템의 한 예는 컴퓨터 기반 비디오 특수효과 시스템이다. 이러한 시스템에서, 일반적으로 사용자는 이용할 수 있는 매우 많은 모듈들로부터 연속한 효과 모듈들을 선택함으로써 비디오 시퀀스에 적용할 복합 특수효과를 설정할 수 있다. 예를 들면, 사용자에 의해 설정되는 일련의 효과는,

(i) 이미지 로더

(ii) 움직임 추적기

(iii) 움직임 추적에 연결되는 조명효과

(iv) 움직임 추적에 연결되는 이미지 재조정(realignment)

을 포함한다.

이들 효과 각각은 프로그램 모듈 혹은 플러그-인으로서 구현될 수 있으며, 이때 데이터는 코어 프로그램의 전체 제어하에서 모듈간에 보내진다. 코어 프로그램 객체(object)와 플러그-인 객체간 인터페이스는 동기되는 것이므로, 프로그램 제어(사실, 다중 태스크 환경에서, 소위 "스레드(thread)")가 플러그-인에 보내지고, 그 후 플러그-인은 그 프로세싱 태스크를 수행한다. 상기 스레드를 사용하여 다른 처리를 재개하기 위해서는 제어를 코어 프로그램으로 돌려보내기만 하면 된다.

본 발명은 소프트웨어 플러그-인에 인터페이스되게 하는 데이터 처리 시스템을 제공하는 한편, 상기 플러그-인들 중 일부를 전용 하드웨어 장치로 대치하여 이를 사용하기 위해 미래에 업그레이드가 가능하게 하는 것 간에 잠재된 모순이 있음을 인식하여 이를 해결하고자 하는 것이다.

본 발명은 코어 프로그램 객체가 데이터 처리 태스크들을 수행하도록 동작할 수 있는 복수의 플러그-인과 상호작용하여 상기 플러그-인의 동작을 제어하며, 상기 코어 프로그램 객체와 각각의 데이터 처리 태스크간에 통신을 제공하는 데이터 처리 장치에 있어서,

(i) 상기 코어 프로그램 객체와 상기 태스크를 수행하도록 동작할 수 있는 의 플러그-인의 상호작용을 가능하게 하는 동기 인터페이스; 및

(ii) 상기 코어 프로그램 객체와 상기 태스크를 수행하도록 동작할 수 있는 하드웨어 플러그-인 간의 상호작용을 허용하는 비동기 인터페이스를 포함한다.

본 발명은 한편으로는 소프트웨어 플러그-인에 인터페이스되게 하는 데이터 처리 시스템을 제공하는 것과, 다른 한편으로는 상기 플러그-인들 중 일부를 전용 하드웨어 장치로 대치하여 이를 사용하기 위해 미래에 업그레이드가 가능하게 하는 것간에 잠재된 모순이 있음을 인식하여 이를 해결한다. 이러한 형태의 전용 하드웨어 장치로서, 특히 렌더링 장치는 일반적으로 비동기 인터페이스를 사용한다. (실제로, 일부 소프트웨어 플러그-인은 비동기 인터페이스를 사용할 수 있다). 따라서, 본 발명은 비동기 및 동기 플러그-인 인터페이스 양자를 제공하는 직관에 반하는 단계를 포함한다.

본 발명의 상기, 및 다른 목적, 특징 및 이점은 첨부한 도면과 관련하여 읽히게 될 예시한 실시예에 대한 다음의 상세한 설명으로부터 명백하게 될 것이다.

도 1은 디지털 비디오 특수 효과 장치를 개략적으로 도시한다.

연속 비디오 이미지들을 포함하는 디지털 비디오 신호는 입력 인터페이스(100)를 통해 수신되고 디스크 어레이 장치(110)에 저장된다. 또한, 디스크 어레이 장치(110)는 장치에 의해 발생된 어떤 조작된 이미지들을 저장하며, 이들 이미지는 출력 인터페이스(120)를 통해 출력될 수 있다.

중앙 처리 장치(CPU)(130)는 사용자 커맨드들에 따라 다양한 비디오 특수 효과들을 실행하기 위하여 디스크 어레이에 저장된 데이터를 액세스한다. CPU(130)는 마우스 및 키보드와 같은 사용자 입력 장치들(140)로부터 입력을 수신하고, 메모리(150)에 태스크 데이터 및 프로그램 코드를 저장하고, 디스플레이 구동기(170)를 통해 디스플레이 스크린(160)상에 출력을 위해 데이터를 발생한다.

상기 장치는 예를 들면 마이크로소프트 윈도우즈 NT® 동작 시스템하에서 적당한 소프트웨어를 실행하는 일반적인 컴퓨터(예를 들면 PC)로서 실행될수 있다. 본 실시예에서, 디스크 어레이는 울트라SCSI 데이터 링크를 통해 CPU(130)에 접속된다.

도 2는 도 1의 장치에 대한 동작 소프트웨어의 편성을 (아주 일반적인 레벨로) 개략적으로 설명한다.

소프트웨어는 프로그램 코드의 두 개의 카테고리들, 즉 도 2의 좌측에 도시된 코어 프레임워크(core framework)와, 도 2의 우측에 도시된 다양한 "플러그-인"으로서 배열된다. 소프트웨어가 초기에 로드되면, 코어 프레임워크는 항상 존재하며, 상이한 특수 효과 처리 사이에 공유된 장치의 동작 부분들을 제어한다. 그와는 반대로, 플러그-인은 (조명 효과, 움직임 트래킹 효과 등과 같은) 개별 특수 효과에 관한 것이며 필요할 때만 로드된다.

이것은 사용자에 의해 요구되는 현재의 효과 모듈들에 관한 플러그-인 만이 메모리내에 로드될 필요가 있기 때문에 아주 효과적인 배열이다. 이것은 모든 가능한 특수 효과용 프로그램 코드가 로드되어야 하는 시스템과 비교하여 메모리를 줄인다(save). 또한 장치의 보다 급속한 초기화를 허용하여, 시스템이 처음 개시될 때 메모리내에 모든 프로그램 코드를 로드할 필요가 없게 되며, 아이콘이 그래프 편집기에서 처음 선택될 때 코드 로드를 통해 지연을 감소시킬 수 있다. 더욱이, 상기 배열은 감소된 서브세트의 장치(특히, 동작 소프트웨어)가 플러그-인들 없이 그래프 편집기 및 코어 처리를 포함하여 공급되거나 설치되는 것을 허용한다. 이 시스템은 플러그-인들과 코어 프레임워크 사이의 한정된 인터페이스 프로토콜에 고정되는 한, 제3자나 사용자가 그들 자체의 플러그-인들을 생성하는 것을 허용한다. 그러므로, 사용자는 비교적 작은 플러그-인 프로그램을 기록함으로써 아주 간단히 주문한 효과를 생성할 수 있다.

코어 프레임워크 및 플러그-인들은 문헌 「"Understanding ActiveX and OLE", David Chappell, Microsoft Press, 1996」에 기재된 소위 "오브젝트 링크 및 내장" (OLE) 프로토콜을 이용하여 서로 통신한다.

OLE 시스템에서, 소프트웨어 설계자는 소위 "COM(Component Object Model) 오브젝트" 로서 컴퓨터 프로그램의 상이한 섹션들을 실행할 수 있다. 각 COM 오브젝트는 다수의 "방법"을 각각 포함하는 하나 이상의 COM "인터페이스"를 지원한다. 한 방법은 특수 동작을 수행하기 위한 기능 또는 절차이다. COM 방법은 COM 오브젝트를 이용하는 소프트웨어에 의해 호출될 수 있다. 시스템은 COM 오브젝트를 이용하는 소프트웨어의 다른 부분들이 한정된 인터페이스를 통해서만 그렇게 행할 수 있도록 제한되며, 그러므로 소프트웨어의 다른 부분들은 한정된 COM 인터페이스를 통하는 것과는 다른 오브젝트내에 프로그램 코드 또는 데이터를 직접 액세스할 수 없다.

본 시스템에서, 코어 프레임워크는 이들 COM 인터페이스들을 통해 플러그-인들과 통신한다. (실제로, 코어 프레임워크는 기본원리는 동일한, COM 인터페이스를 제공할 수 있는 복수의 상호통신 오브젝트들을 포함한다).

도 3은 도 2에 도시된 것보다 더 상세하게 동작 소프트웨어의 편성을 설명한다. 도 3에서, 도표는 4개의 사분면들로 분할된다. 상부 좌측 사분면은 소위 뷰어 윈도우(310)를 도시한다; 상부 우측 사분면은 효과 사용자 인터페이스(UI)(320)를 도시한다; 하부 우측 사분면은 연관된 파라미터 데이터(PD)를 가지는 효과 "서버"(330)를 도시한다; 하부 좌측 사분면은 오브젝트 관리자(350), 렌더 관리자(352) 및 변화 관리자(358)와 함께 그래프를 포함하는 코어 처리기(340)를 도시한다. 하부 좌측 및 하부 우측 사분면 사이의 인터페이스에는 윈도우즈 NT 레지스트리의 일부를 형성하는 메타 데이터베이스(354), 및 효과 아이콘과 디폴트 파라미터값을 포함하는 팔레트(356)가 있다. 메타 데이터베이스(354)는 도 11을 참조로 기술될 것이며 팔레트는 도 6 내지 도 9를 참조로 기술될 것이다.

코어 처리기(340) 내에는 그래프 - 실제로 링크된 일련의 개별 특수 효과를 가지는 "방향성 비순환 그래프(directed acyclic graph)"가 있다. 각 효과는 이용가능해지자마자 효과의 출력을 저장하기 위한 연관된 캐시(C)를 가지는 프록시 효과(PE)로서 그래프에 나타나며, 그로인해 예를 들면 체인에서 더 높은 효과와 연관된 파라미터가 변화될 경우, 효과 체인에서 효과로부터 데이터의 재사용이 허용된다. 각 프록시 효과는 각 효과 서버(330)와 연관된다.

오브젝트 관리자(350)는 시스템에서 능동 오브젝트의 수명 및 메모리 관리를 제어하는데 응답가능하다. 렌더 관리자(352)는 개시, 진행, 우선순위 및 렌더 태스크의 정지를 제어한다. 변화 관리자(358)는 시스템의 여러 가지 부분에 대한 변화의 통지 및 취소/재개(undo/redo) 정보를 제어한다.

도 3의 기본 분할에서, 두 개의 좌측 사분면(상부 좌측 및 하부 좌측)은 어떤 특수 효과에 특정되지 않은 코어 프레임워크의 특징에 관한 것이다. 이들 오브젝트는 사용자가 실행하기를 원하는 어느 특정한 특수 효과에 관계없이 메모리내에 로드된다. 두 개의 우측 사분면(상부 우측 및 하부 우측)은 플러그-인에 관한 것이다. 각 플러그-인은 플러그-인에 의해 수행된 효과와 연관된 처리를 수행하는 서버(330)와, 상기 효과에 관련된 사용자 인터페이스 제어(실제로, 뷰어 윈도우(310)에서의 디스플레이를 위해)를 제공하는 사용자 인터페이스(320)를 가진다.

도 3에는 유사한 상부-하부 분할이 있으며, 그로인해 두 개의 상부 사분면들(상부 좌측 및 상부 우측)은 특수 효과와 연관된 사용자 인터페이스 제어에 관한 것이고, 두 개의 하부 사분면들(하부 좌측 및 하부 우측)은 상기 효과를 실행하기 위해 수행되는 처리 및 편성에 관한 것이다.

뷰어 윈도우는 장치에 의한 실행을 위해 형성된 일련의 효과에서 특정 효과에 대한 제어 파라미터 및 효과의 출력을 뷰잉하기 위한 기회를 사용자에게 제공한다. 그래서 뷰어 윈도우가 사용자에 의해 개방되면, 효과의 출력은 발생되거나 또는 이용가능하다면 캐시 저장부로부터 복원되어야 한다.

다중 COM 오브젝트를 사용하는 이러한 형태의 시스템에서, 일반적으로 각 오브젝트가 별도의 데이터 파일에 태스크 또는 결과 데이터를 저장하는 것은 바람직하지 않은 것으로 생각된다. 실제로, 이러한 배열은 OLE 시스템을 구축하는 많은 추론에 대항할 것이다. 그 대신에, 이러한 형태의 시스템에서의 데이터는 단일 파일이나 "복합 문서"의 모든 오브젝트에 의해 저장되지만, 상기 복합 문서내에 순서 구조(ordered structure)를 갖고 저장된다.

기본적으로, 복합 문서 내부에는, 파일 및 디렉토리 구조와 유사한 구조가 제공된다. 디렉토리의 등가는 소위 "기억장치(storage)"이며, 파일과 유사한 것은 소위 "스트림"이다. 각 복합 문서는 기억장치 및 스트림의 유사 트리 구조인 루트 기억을 포함한다. COM 스트림 인터페이스는 COM 기억 인터페이스보다 더 간단하지만, 물론 기억 인터페이스는 더 유연성을 제공한다.

일반적으로, 각 COM 오브젝트는 태스크 데이터가 저장되는 자체 스트림 혹은 자체 스토리지에 할당될 수 있다. 그러나, 비디오 특수 효과 처리기와 같은 계층적 시스템에서, 코어가 복수의 플러그-인의 동작과 통합될 경우, 종전 시스템에 사용되던 배열은 각 효과 플러그-인에 스트림을 할당하는 것이다.

대조적으로, 본 실시예에서, 플러그-인에 기억장치나 스트림을 간단히 할당하는 것은 설계 및 플러그-인 오브젝트의 동작에 대한 많은 제한을 가져온다는 것이 인지될 것이다. 그 대신에, 코어 및 플러그-인 사이의 인터페이스 정의(definition)에서 각 플러그-인은 스트림 중에서 선택할 수 있으며, 따라서 플러그-인 설계자가 원할 경우 직접적(straightforward)인 방법으로 태스크 데이터를 저장할 수 있으며, 기억장치를 선택함으로써 원할 경우 스트림들 및 기억장치들의 자체 "디렉토리" 배열하에서 태스크 데이터를 저장할 수 있다. 이 선택은 플러그-인 프로그램 코드를 생성하는 플러그-인 설계자에 의해 미리 행해진다.

다음의 상세한 설명에서, 여러 가지 오브젝트 사이의 통신 프로토콜은 도 4 및 도 5를 참조로 기술될 것이다. 코어 프로그램의 그래프 편집 부분이 합성 효과를 형성하기 위하여 일련의 개별 효과를 설정하는데 사용되는 방법이 도 6 내지 도 9를 참조로 기술된다. 뷰어 윈도우 및 효과 UI들(320)과의 상호작용이 도 10을 참조로 기술될 것이다.

도 4는 도 3의 배열에서 갱신된 효과 파라미터의 전파를 개략적으로 설명한다.

이 상황의 일 예는 사용자가 "조명" 특수 효과를 셋업하는 것이며, 광원의 효과가 이미지에 부가된다. 광원은 사용자-정의 가능 소스 및 이미지에 대한 행선지 위치를 가진다. 사용자가 이들 위치들중 하나를 변경하기 원할 경우, 이것은 상기 효과로부터 현재 렌더링된 어떠한 출력도 무효화 할 것이며, 도 3의 상이한 사분면에 도시된 여러 가지 오브젝트 사이에도 변경이 전파될 필요가 있다. 이 처리는 도 4에 도시되어 있다.

도 4에서, 사용자는 뷰어 윈도우(310)(도 10참조)를 통해 변화된 파라미터에 들어간다. 뷰어 윈도우는 특정 효과 UI(320)와 연관되며, 개별 효과에 관련된 플러그-인의 일부이다. (실제로, 단일 뷰어 윈도우는 하나의 효과보다 더 많이 연관되어 있으며, 모든 효과들은 어떤 특정 시간에 뷰어 윈도우를 개방하는 것은 아니며, 도 3의 간단화된 배열은 이 내용을 위해 유지될 것이다). 플러그-인은 코어에 "편집에 관하여" 통지를 송출한다.

변화된 후에, 플러그-인은 "변화가 일어남'이라는 메시지를 송출한다. 이것은 일련의 동작들을 수반하거나 개시한다. 제1단계 401에서, 뷰어 윈도우는 효과 UI(320)에 갱신된 파라미터를 전송한다. 효과 UI(320)는 대응하는 효과 서버(330)에 "세트" 커맨드를 송출하여, 효과 서버(330)내의 파라미터 저장부에 수정된 값을 세팅한다. 이것은 도 4에서 단계 402이다.

단계 403에서, 효과 서버(330)는 코어 내에 "취소/재개" 오브젝트를 기록하여, 변화 전후로 파라미터의 기록(효과 서버에서)을 가리키는 핸들이나 포인터의 상세를 제공한다. 이 취소/재개 오브젝트의 수신에 응답하여, 단계 404에서 코어는 파라미터가 변화되고 일부 캐시 데이터 출력이 무효될 수 있다는 것을 모든 뷰어 윈도우에 알린다. 이 알림은 파라미터 변화가 일어나는 뷰어 윈도우에 한정되지 않는다.

단계 405에서, 각 뷰어 윈도우는 그 처리 파라미터의 갱신을 요구하는 대응 효과 UI(320)에 메시지를 송출한다. 단계 406에서, 효과 UI(320)는 새로운 파라미터를 얻기 위하여 대응 효과 서버에 "get"커맨드를 송출하며, 새로운 파라미터는 단계 407에서 효과 UI(320)로 복귀된다. 이어서 효과 UI(320)는 단계 408에서 뷰어 윈도우에서의 디스플레이를 위해 변화를 전파한다.

일반적으로, 처리 파라미터가 변화될 경우, 이것은 하나 이상의 효과의 출력을 렌더링할 필요를 초래한다. 도 5는 리-렌더 커맨드가 장치를 통해 전파되는 방법을 설명하며, 도 4의 처리에 후속한다.

단계 502에서, 뷰어 윈도우는 렌더 관리자에 리-렌더 커맨드를 송출한다. 이어서 렌더 관리자는 대응하는 효과 서버(330)에 리-렌더 커맨드를 송출한다. 효과 서버(330)가 이미지를 리-렌더링하는 것을 완료하면, 코어에 "완료" 메시지를 송출한다. 코어는 단계 505에서 뷰어 윈도우에 이것을 연결시키고, 단계 506 및 507에서, 뷰어 윈도우는 리-렌더링된 효과 출력을 디스플레이하기 위하여 효과 UI(320)과 대화한다.

여러 개의 뷰어 윈도우 개방, 및 중요한 영역에서 여러 개의 프레임(전체 비디오 클립의 서브세트(테스트 목적)로서 사용자에 의해 한정될 수 있음)이 있는 경우, 이미지는 다음과 같은 처리 자원을 할당하기 위해 우선순위에 따라 다중 동시 태스크으로서 렌더링된다:

(i) 사용자에 의한 뷰잉을 위해 현재 디스플레이된 이미지

(ii) 중요한 출력 시퀀스의 최초 및 최종 이미지

(iii) 중요한 출력 비디오 시퀀스의 나머지 이미지

추가 레벨의 상세로서, 렌더 관리자가 효과 서버에 리-렌더 커맨드를 송출하기 전에, 렌더 관리자는 시퀀스에서의 이미지가 렌더링되는 것을 설명하는 "렌더링 준비" 메시지를 송출한다. 효과 서버는 "종속(dependency)", 즉 렌더 관리자에 의한 요구가 실행될 수 있기 전에 필요한 렌더링된 이미지의 알림에 응답한다. 이 이미지들은 다른 효과(예를 들면 방향성 비순환 그래프에서 바로 선행하는 효과)에 의해 렌더링된 이미지이거나 효과 자체에 의해 렌더링된 이미지일 수 있다. 후자 경우는 이미지5를 렌더링하기 위하여 움직임 트래커가 자체 렌더링된 이미지4에 대한 출력을 필요로 하는 경우, 움직임 트래커의 예에서 일어날 수 있다.

효과 서버로부터 다시 수신된 메시지에 응답하여, 렌더 관리자는 종속 트리(dependency tree)가 종료될 때 까지 이들 이미지를 요구하는 "렌더링 준비" 메시지를 전송한다.

각 스테이지에서, 효과 프록시는 요구된 이미지나 렌더링된 출력이 캐시되는지를 체크하고 렌더 관리자에게 알린다.

예를 들면, 렌더링 준비 메시지가 이미지 5를 지정하는 움직임 트래커에 전송되면, 이미지4에 대해 렌더링된 출력을 요구하는 것에 응답할 수 있다. 이어서 렌더 관리자는 이미지4에 대한 움직임 트래커에 렌더링 준비 메시지를 전송하며, 움직임 트래커는 이미지3을 필요로하는 것을 지시하기 위하여 응답한다. 이러한 방법으로 필요한 이미지(이미지 5)가 렌더링될 수 있기 전에 필요로 하는 렌더링 태스크 리스크가 형성된다. 캐시에 지지되는 렌더링된 출력은 렌더 관리자의 태스크 리스트에 포함되지 않는다.

동일한 것은 효과가 선행 효과의 렌더링된 출력을 필요로하고 일련의 효과를 다운시키는 경우에 일어난다.

이 처리의 종료시에, 렌더 관리자는 필요로하는 태스크 수행을 모두 세팅하고, 반대의 순서로 현재 필요로하는 이미지는 그 종속 이미지 모두가 렌더링될 때 까지 렌더링되지 않는다.

최적화로서, 렌더 관리자는 그래프로부터 각 효과에 대한 입력이 어떤 것인지를 검출할 수 있다. 그러므로, 효과 서버는 "이 효과에 대한 모든 입력들이 요구됨"을 간단히 하기 위해 소정의 코드(에를 들어 널(null) 응답)를 전송할 수 있다.

추가 확장으로서, 동일한 프로토콜이 사용될 수 있으며, 그로 인해 각 효과 서버는 그 출력이 인접 이미지들 사이에서 동일한 경우 렌더 관리자에게 알릴 수 있다. 이것의 간단한 예는 출력이 불변인 경우 (고정된) 파라미터 플러그-인이다. 다른 예는 출력이 이미 준비되고 캐시되어, 연속 출력이 동일한지에 대하여 직접 검출이 행해질 수 있는 어떤 다른 효과이다. 이러한 알림에 응답하여, 렌더 관리자는 방향성 비순환 그래프에 추후 존재하는 효과 서버상에 정보를 패스한다. 이 효과 서버는 이미지의 범위중 하나만을 렌더링하고, 입력이 동일하게 남아있는 다른 이미지에 대하여 상기 출력을 반복할 수 있다.

도 6은 그래프 편집 윈도우(600) 및 팔레트 윈도우(610)를 개략적으로 설명한다. 이들은 코어 처리기(340)의 제어하에서 디스플레이 스크린(160)상에 디스플레이된다.

팔레트 윈도우(610)는 플러그-인이 시스템상에 존재하는 여러가지 가능한 효과들을 나타내며 상기 효과에 각각 매핑되는 복수의 아이콘들(620)을 포함한다. 마우스 제어를 이용하여, 사용자는 이들 아이콘들을 스크롤가능한 그래프 윈도우(610)내에 "드래그(drag)"할 수 있다. 아이콘들은 서로에 대하여 그래프 윈도우에서 사용자에 의해 배열되며 그래픽 라인으로 윈도우에 도시된 논리 링크들(630)과 함께 링크된다.

링크들(630)는 다음 효과의 입력에 대한 효과의 출력의 패스를 나타내며, 항상 그래프의 하부로부터 그래프 윈도우의 상부쪽으로의 방향을 갖는다. 그러므로, 도 6에 도시된 예는 조명 효과(650)에 대한 출력을 패스하는 이미지 로더 아이콘(640)을 갖는다.

사용자가 그래프 윈도우에서 그래픽 링크를 셋업하면, 코어 처리기(340)는 렌더링된 출력이 하나의 효과 플러그-인으로부터 다른 것으로 패스되는 방법을 결정하기 위하여 논리 링크를 셋업한다.

그래픽 링크가 생성되는 방법을 도 7을 참조로 설명한다. 논리 링크는 도 9를 참조로 기술될 것이다.

도 7에서, 사용자는 조명 효과를 선택하며(예를 들면, 마우스 클릭), 아이콘(650)으로부터 마우스 포인터(730) 쪽으로 향하는 이동가능한 그래픽 라인(720)을 갖는다. 마우스 포인터가 혼합 효과 아이콘(700)에 접근하면, 혼합 효과 아이콘은 확대되거나 또는 보더(740)의 하부에서 두 입력 포트를 도시하는 확장부(710)에 의해 둘러싸여진다. 마우스 포인터가 입력 포트중 하나에 접근하면, 그래픽 라인은 상기 입력 포인트 상에서 스냅되며 마우스 클릭으로 적절히 고정될 수 있다. 이것은 효과(650)와 효과(700)사이의 논리적이고 그래픽적인 접속을 형성한다.

이들 논리 및 그래픽 접속이 형성되면, 사용자는 그래픽 윈도우에서 효과 아이콘의 링크된 그룹(800)을 "박스(box)"할 수 있다. 여기에서, "박스"하는 것은 컴퓨터 마우스를 이용하는 표준 방법으로 그룹 주위에 박스를 그리는 것을 의미한다. (이것이 실시되는 한가지 방법은 박스의 상부 좌측 코너에서 클릭 및 유지하고, 마 우스를 하부 우측 코너로 드래그하고, 마우스 버튼을 해제한다).

사용자는 효과의 링크된 그룹을 팔레트 영역안으로 드래그할 수 있다. 이것은 그룹의 출력으로부터 형성된 한 세트의 출력과 그룹에 대한 입력으로부터 형성된 한 세트의 입력을 가지는 새로운 합성 효과 아이콘(810)을 생성한다. 논리적인 측면에서, 특정 플러그-인에 매핑되는 효과 아이콘(810) 대신에, 특정 방법으로 접속된 링크된 그룹의 플러그-인에 매핑된다.

합성 효과 아이콘(810)은 그래프 설계에 있어서 사용자에 의한 사용을 위해 팔레트의 일부를 형성한다. 후에, 사용자가 합성 아이콘(810)을 사용하고 싶을 경우, 아이콘을 그래프 윈도우상의 위치로 간단히 드래그하면 된다. 바람직하게는, 효과 아이콘(810)은 그래프 윈도우상에 단일 아이콘으로서 남아있으며, 다른 실시에서는 최초 그룹(800)으로 확장될 수 있다. 다른 실시예로서, 디스플레이된 "확장" 버튼을 가지는 압축된 형태에서 디스플레이될 수 있으며, 그것에 의해 사용자는 최초 그룹의 아이콘(800)을 디스플레이하기 위하여 확장 버튼을 클릭할 수 있다. 어떤 경우에는, 아이콘(810)에 의해 제공된 합성 효과는 최초 그룹(800)의 복사이다.

도 9는 상기 처리 과정 하의 데이터 스토리지를 나타낸다. 도 9에서 아이콘(850)은 팔레트 영역(600)의 팔레트 아이콘들(620)로부터 그래프 편집기 영역(610)으로 드래그되었다.

루트(860) 및 루트에 의존하는 개별 데이터 항목(870)으로서 배열된 데이터 구조는 팔레트 영역(600)과 연관되며, 도 3에 도시된 팔레트(356)에 저장된다. 각 데이터 항목(870)은 효과(875)와 같은 합성 효과의 경우를 제외하고 하나의 효과 아이콘(620)을 나타낸다. 여기에서, 효과를 형성하는 효과 아이콘들(3a, 3b)은 데이터 항목(875)에 의존하는 서브구조에서 배열된다.

유사한 데이터 구조가 그래프 편집 영역에서 효과를 저장하기 위해 존재한다. 여기에서, 루트(880)는 그것에 의존하는 단지 하나의 효과(885)를 갖는 것으로 도시되어 있다. 복수의 효과가 그래프 편집 영역에 함께 그룹화되어 팔레트에 드래그되면, 구조(875)와 유사한 또다른 합성 효과 구조를 형성한다.

도 10은 뷰어 윈도우를 개략적으로 도시한다. 뷰어 윈도우는 이미지 디스플레이 영역(900), 여러 가지 "특성 페이지"(910), 효과 제어(920)(여기에서 조명 효과의 예에서 위치설정 크로스-와이어로서 도시됨), 및 "버튼 바"(930)를 포함한다.

뷰어 윈도우의 기본 레이아웃은 코어 프레임워크에 의해 세팅되고, 효과간의 표준이다. 그러나, 특성 페이지(property page)(910)를 이용하여 조절될 수 있는 특정 항목은 특정 효과에 대응하는 효과 UI(320)에 의해 세팅된다. 효과 UI(320)는 제어(920)에 대한 디스플레이 상세를 제공한다.

도시된 일 예에서, 크로스-와이어(920)는 조명 효과에서 광의 소스 또는 타겟 위치를 결정한다. 사용자는 컴퓨터 마우스를 이용하여 크로스-와이어를 드래그할 수 있다. 크로스-와이어를 드래그하는 것은 상기 제어와 연관된 파라미터(x,y)값을 변화시키고 도 4의 절차(파라미터값 갱신)가 개시된다. 상기 절차의 마지막 부분으로서, 단계 408에서, 효과 UI는 뷰어 윈도우에 정정된 파라미터값을 송출한다. 상기 스테이지에서, 크로스-와이어는 새 위치로 다시 그려진다. 그러므로, 드래그 동작이 크로스-와이어를 궁극적인 위치로 이동시킨 것을 사용자가 나타낼지라도, 실제 로 드래그 동작은 도 4에 도시된 루트에 의해 크로스-와이어의 이동이 초래되는 파라미터 갱신을 형성한다.

도 11은 동작 소프트웨어의 초기 배열을 개략적으로 설명한다. 이것은 어떤 렌더링이 장치의 특정 동작 기간에 수행되기 전의 상황을 나타낸다.

플러그-인은 "동적 로드 라이브러리(DLL)"로서 윈도우 운영 시스템하에서 실행된다. DLL은 프로그램 코드, 데이터 및 서브루틴 라이브러리를 포함할 수 있는 대형 파일이다. 종래, 메모리를 보존하고 시스템성능을 개선시키기 위하여, DLL은 DLL에 의해 처리된 특정 프로세스의 실행 또는 개시를 위해 처음 필요할 때 메모리내에 로드된다. 이 실시예에서, 메모리를 보존하고 시스템 성능을 개선시키는 사상이 한 단계 더 나아간다.

그래서, 어떤 효과 아이콘이 팔레트 영역으로부터 먼저 취해질 때, 상기 효에 대응하는 DLL은 코어에 만들어질 그래프에 대한 충분한 정보(예를들어, 다른 효과 아이콘과 상호접속성)를 제공하기 위하여 메모리에 로드된다.

본 실시예에서는, 상기 효과에 대한 DLL이 상기 스테이지에서 로드되지 않는다. 대신, 소위 상기 효과를 나타내는 "메타데이터(metadata)" (1000)이 로딩된다. 메타데이타는 다른 효과(예를들어, 입력 및 출력 수)를 가지는 효과의 상호접속성을 제한하는 정보를 코어에 제공한다. 이것은 코어가 임의의 DLL를 로드할 필요없이 그래프를 만들도록 하여, 메모리가 절대적으로 필요할때까지 많이 로딩함으로써 메모리를 절약한다.

만약 뷰어 윈도우가 효과에 관련하여 개방되거나, 합성 효과가 임의의 다른 수단에 의해 실행되면, DLL은 로딩되고 메타데이타는 버려지거나 무시된다.

도 12 내지 도 14는 시스템의 자동화를 촉진하는 효과 플러그 인(plug-in) 특징을 개략적으로 도시한다.

도 12는 이미 제안된 효과 플러그 인을 개략적으로 도시한다. 이 효과는 이미지 정보("클립" 1300으로서 도시됨)를 취하고 3개의 처리 파라미터 P1, P2 및 P3(라이트 위치 같은)를 바탕으로 작동한다. 도 12의 플러그 인에서, 파라미터 값은 플러그 접속식 부분으로서 기록된 예약된 프로그램 코드에 의해 플러그 인내에 설정된다. 이것은 파라미터가 시간에 따라 변화하는 경우 애니메이션 시스템에 대해, 또는 라이트 위치같은 파라미터가 효과 플러그 인내의 부가적인 코드 및 종종 효과 플러그 인의 다중 버전을 요구하는 매우 어려운 움직임 트랙커 같은 다른 효과에 의해 변화되는 장치에서 파라미터를 전체적으로 제어한다.

도 13은 본 발명의 실시예에 따른 다른 방법을 개략적으로 도시한다. 여기서, 각각의 파라미터는 효과 사이의 링크가 전술한 그래프 편집기로 한정되는 것과 동일 방식으로 "메인" 효과 플러그 인(1330)에 접속된 분리된 플러그 인(1320)에 의해 한정된다. 실제적으로, 전술한 설명은 전체적인 처리의 간략화이고, 상기 간략화는 설명을 돕기 위하여 상기 스테이에서 이루어진다.

파라미터 플러그 인은 "페이지를 오프"하는 그래프 편집기 및 팔레트의 스크린 위치에 디스플레이함으로써 사용자로부터 숨겨진다.

그래서, 만약 효과가 자체 포함된(self-contained) 비 애니메이트 방식(즉, 다른 효과로부터의 파라미터 값을 포함하지 않고)으로 동작되면, 메인 효과 뷰어 윈도우를 사용하는 각각의 파라미터 플러그 인(1320)에 파라미터가 설정된다.

만약 파라미터가 다른 효과 출력, 예를들어 움직임 트랙킹 효과에 의해 제공된 위치 값에 의해 정의되면, 메인 효과 플러그 인(1330) 및 분리될 적당한 파라미터 플러그 인(1320) 사이의 논리적 링크 및 움직임 트랙킹 효과에 대한 링크를 위해 초기화 되는 경우, 그 모든 것이 요구된다.

이 시스템이 어떻게 애니메이션에 도움을 줄수있는가를 이해하기 위하여, 도 14를 참조한다.

도 14는 도 3에 첫 번째로 도시된 코어 및 플러그 인 사이의 왼쪽-오른쪽 스플릿을 도시한다. 도 14의 좌측에, "메인" 효과 서버(1350)를 위하여 프록시 효과(1340)가 제공된다. 프록시 효과(1360)는 파라미터 플러그 인(1320) 각각을 위하여 제공된다. 이들 프록시 효과(1360)는 프록시 효과(1340)보다 간단한 성질이고, 프록시 효과(1360) 및 파라미터 플러그 인(1320) 사이의 통신은 프록시 효과(1340) 및 효과 서버(1350) 사이 통신 프로토콜의 간략화된 서브세트를 사용한다.

실제적으로, 프록시 효과(1360)는 애니메이션 시스템에서 하나의 데이터 값(애니메니트된 시스템이 아닌 곳에서) 또는 애니메이트된 시스템에서 값의 목록일 수 있다. 애니메이트된 시스템에서, 값의 목록은 "키 프레임" 값, 즉 시퀀스에서 특정 이미지에 대한 데이터 값 세트로서 표현되고, 인터리빙 값은 선형 또는 사용자 정의 비선형 보간법에 따라 코어에 의해 보간된다. 그래서, 애니메이션은 특히 간단하게 설정되고, 각각의 플러그 인 내에 예약된 애니메이션 소프트웨어를 기록하기 위하여 구비하지 않는 편리한 방식으로 설정될 수 있다.

효과 사이의 의존성에 대하여 전술한 설명과 관련하여, 렌더 관리자로부터 "렌더하도록 준비" 메시지가 효과 서버(1350)에 의해 수신될 때, 출력이 제공되기 전에 입력 모두를 요구하는 것을 기리키도록 응답한다. 효과 입력에는 파라미터 플러그 인 코스가 포함되고, 다음 단계는 렌더 관리자가 각각의 플러그 인에 렌더 메시지에 대한 준비를 전송하게 하는 것이다. 만약 파라미터 플러그 인이 하나의 값을 포함하거나, 현재 이미지가 키 프레임이면, 파라미터 플러그 인은 렌더 시간에 적당한 파라미터를 제공할 준비를 한다. 그러나, 만약 파라미터 플러그 인이 애니메이션 데이터를 포함하고 현재 이미지가 키 프레임이 아니면, 파라미터는 그것이 효과에 사용되기전 보간되어야 한다.

도 15는 시스템 캐쉬(1100)를 개략적으로 도시한다. 이것은 전체 캐시 영역의 개략도이다-실제적으로, 전술한 바와같이 캐쉬는 메모리 리소스가 상기 각각의 캐쉬 사이에 다이나믹하게 할당되기 때문에 각각의 프록시 효과와 연관된 복수의 각각의 캐시로서 도시될 수 있고, 도 15의 도면은 유효한 하나의 캐쉬이다.

캐쉬는 시스템 메모리(150)에 제공되고 이미지(1110) 및 효과(예를들어 움직임 트랙킹 효과의 경우 움직임 벡터)로부터 비이미지 렌더 출력(1130)을 저장할 수 있다.

캐시는 비순환 그래프에서 각각의 효과의 렌더 출력(이것이 이미지인지 아닌지)을 저장한다. 이런 방식에서, 만약 효과가 방향성 비순환 그래프의 특정 위치에서 변경되면, 상기 위치 하의 효과는 새로운 출력을 제공하기 위하여 다시 렌더될 필요가 없다. 추가의 이익은 파라미터 변화가 이루어지기 전후 특정 효과(개방된 뷰어 윈도우)의 출력을 저장함으로써 취소/재개 동작을 돕고 속도를 올린다는 것이다. 대응하는 파라미터 변화가 저장되어, 파라미터 변화는 캐쉬 메모리(1100)로부터 적당한 재료를 로딩함으로써 간단히 취소 및 재개된다. 이것은 변화가 이루어질 때 이펙터 서버에 의해 기록된 취소/재개 목적의 제어하에서 이루어진다.

이미지는 움직임 벡터와 같은 간단한 데이터 값보다 많은 메모리 공간을 차지한다-아마도 메모리 공간보다 백만배정도. 그래서, 이 실시예에서, 캐쉬 메모리가 그의 용량에 도달하고 다른 이미지가 저장될 때, 캐쉬에 가장 마지막에 액세스된 이미지는 새롭게 저장된 이미지를 위한 룸을 만들기 위하여 삭제된다. 그러나, 캐쉬의 다른 데이터-파라미터 값, 이미지가 아닌 출력 등은 그것이 이미지와 비교하여 작은 양의 메모리 공간을 차지하기 때문에 장치의 동작 세션 동안 삭제되지 않는다. 이런 정보는 정보가 동작 세션을 통해 유효하게 남아있는한 재상, 또는 취소/재개에 이용할 수 있다.

실제적으로, 데이터 항목이 넘치는지 아닌지를 플러그 인이 나타내는 것이 남겨질 수 있고, 이미지 데이터 항목은 넘치는 것으로 약정에 의해 설정되고, 이미지 아닌 항목은 넘치지 않는 것으로 설정된다.

도 16은 코어 및 효과 서버 사이의 비동기-동기 변환기(1200)를 도시한다.

변환기(1200)는 "해야할" 대기 행렬, 즉 행해질 렌더링 잡의 목록 형태로 렌더 관리자로부터 비동기 리렌더링 명령을 수신한다. 잡이 끝날 때, "끝냄" 메시지가 변환기(1200)로부터 렌더 관리자로 리턴된다.

변환기(1200)는 비동기 잡 요구를 수신하고 적당한 소프트웨어 플러그인에 동기 요구를 내린다. 이것은 인터페이스(1200)가 제어 "스레드"(윈도우 텀)를 소프트웨어 플러그 인에 통과시키고, 잡이 완료될때까지 스레드를 제어한다. 그리고나서, 소프트웨어 플러그 인은 쓰레드를 인터페이스로 리턴하고, 코어에 "끝냄" 메시지를 내림으로써 응답한다.

초기화시, 코어는 플러그 인이 동기 통신을 처리하는지 비동기 통신을 처리하는지를 결정하기 위하여 각각의 플러그 인(또는 플러그 인과 연관된 메타데이타)에게 문의한다. 만약 하드웨어 플러그 인(예를들어, 특정 방식으로 렌더링하기 위한 주변 카드) 또는 비동기 소프트웨어 플러그 인-아마도 다른 장치상에서 운행될-이 소프트웨어 대신에 설치되었다면, 상기 플러그 인은 하드웨어 액셀레이터가 이런 방식으로 동작하기에 보다 적당하면, 비동기 인터페이스를 통하여 코어(실제로 비동기적으로 태스크를 렌더링하기 시작하는 렌더 관리자)와 상호작용한다.

변환기는 코어 부분 또는 각각의 관련 플러그 인 부분으로서 실행될 수 있다.

따라서, 소프트웨어의 두 부분 사이에 변환기(1200)를 제공하는 카운터 직관 단계에 의해, 효과적인 하드웨어 인터페이스는 전용 하드웨어로 추후 업그레이드를 위하여 제공된다.

비록 본 발명의 도시적인 실시예가 첨부 도면을 참조하여 상세히 기술될 지라 도, 본 발명은 상기 실시예로 제한되지 않고, 다양한 변화 및 변형은 첨부된 청구범위에 의해 한정된 바와같이 본 발명의 범위 및 사상으로부터 벗어나지 않고 당업자에 의해 이루어질 수 있다.

이상과 같이, 본 발명에 따르면 한편으로는 소프트웨어 플러그-인에 인터페이스되게 하는 데이터 처리 시스템을 제공하는 것과, 다른 한편으로는 상기 플러그-인들 중 일부를 전용 하드웨어 장치로 대치하여 이를 사용하기 위해 미래에 업그레이드가 가능하게 하는 것간에 잠재된 모순이 있음을 인식하여 이를 해결할 수 있다.

Claims (3)

1. 코어 프로그램 객체(core program object)가 데이터 처리 태스크들을 수행하도록 동작할 수 있는 복수의 플러그-인(plug-in)들과 상호 작용하여 상기 복수의 플러그-인들의 동작을 제어하며, 상기 코어 프로그램 객체와 상기 각각의 데이터 처리 태스크 간의 통신을 제공하는 데이터 처리 장치에 있어서:

   (i) 상기 코어 프로그램 객체와 상기 태스크를 수행하도록 동작할 수 있는 플러그-인 프로그램 객체들 간의 상호작용을 허용하는 동기 인터페이스; 및

   (ii) 상기 코어 프로그램 객체와 상기 태스크를 수행하도록 동작할 수 있는 하드웨어 플러그-인 간의 상호작용을 허용하는 비동기 인터페이스를 포함하는, 데이터 처리 장치.
2. 제 1항에 있어서, 상기 코어 프로그램 객체와 관련된 동기/비동기 변환기를 포함하는, 데이터 처리 장치.
3. 제1항에 있어서, 하나 이상의 플러그-인 객체들은 각각의 관련된 동기/비동기 변환기들을 갖는, 데이터 처리 장치.

Images