KR100663655B1 - 데이터 처리 방법 및 데이터 처리 장치 - Google Patents

Abstract

메모리를 가지는 데이터 처리 장치에 의한 실행을 위해, 합성 데이터 처리 동작이 가능한 데이터 처리 서브동작들의 세트로부터 선택된 서브동작들의 유향 비순환 그래프로서 사용자에 의해 어셈블되는 데이터 처리 방법은, 서브동작이 상기 합성 동작내에 포함하도록 상기 사용자에 의해 선택될 때, 상기 서브동작의 입력 및 출력 인터페이스들을 포함하는 상기 서브동작의 파라미터들을 정의하는 서브동작 데이터를 상기 메모리내에 로딩하는 단계; 및 서브동작의 실행의 개시에 응답하여, 상기 데이터 처리 장치에 의한 실행을 위해 서브동작 프로그램 코드를 상기 메모리내에 로딩하는 단계를 포함하며, 상기 서브동작 데이터는 상기 서브동작 프로그램 코드보다 적은 메모리 공간을 필요로 한다.

합성 데이터 처리 동작, 데이터 처리 서브동작, 서브동작 데이터, 서브동작 프로그램 코드, 로딩수단

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은 플러그-인 인터페이스를 개략적으로 도시한 도면.

<도면의 주요 부분에 대한 부호의 설명>

100 : 입력 인터페이스 110 : 디스크 어레이

120 : 출력 인터페이스 130 : CPU

140 : 사용자 입력 장치 150 : 메모리

170 : 디스플레이 구동기 310 : 뷰어 윈도우

320 : 효과 사용자 인터페이스 330 : 효과 서버

350 : 오브젝트 관리자 352 : 렌더 관리자

354 : 메타 데이터 베이스 356 : 팔레트

1310, 1330 : 효과 플러그인 1350 : 효과 서버

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

종래 기술의 설명
일부 컴퓨터-기반 데이터 처리 시스템들은 "코어(core)" 컴퓨터 프로그램 및 복수의 가능한 프로그램 모듈들 또는 필요로할 때 로딩될 수 있는 "플러그-인들(plug-ins)"을 사용한다.

다양한 마이크로소프트 윈도우즈® 동작 시스템들로부터 전문용어를 사용하면, 프로그램 모듈들이나 플러그-인들은 "동적 로드 라이브러리들(dynamic load libraries)" 또는 "DLL들"로서 제공될 수 있다. DLL들은 일반적으로 프로그램 코드, 데이터 및 서브루틴 라이브러리들을 포함할 수 있는 대형 파일들이다. DLL들은 현재 프로그램의 실행을 위해 필요할 때 메모리내에 로딩된다.

이러한 형태의 구조가 사용될 수 있는 데이터 처리 시스템의 일 예는 컴퓨터-기반 비디오 특수 효과 시스템이다. 이러한 시스템에서, 사용자는 대다수의 이용가능한 모듈들로부터 일련의 효과 모듈들을 선택함으로써 비디오 시퀀스에 인가되는 합성 특수 효과를 셋업할 수 있다. 예를 들면, 사용자에 의해 셋업된 효과들의 시퀀스(또는 "유향 비순환 그래프"(directed acyclic graph))는, (i) 이미지 로더(image loader), (ii) 움직임 트래커(motion tracker), (iii) 움직임 트래킹 및 이미지 로더에 링크된 조명 효과, (iv) 움직임 트래킹 및 이미지 로더에 링크된 이미지 재정렬을 포함한다.

이들 효과들의 각각은 프로그램 모듈이나 플러그-인으로서 구현될 수 있으며, 데이터는 코어 프로그램의 전체 제어하에서 모듈들 사이에 라우팅(route)될 수 있다. 이러한 형태의 시스템에서, 현재 선택된 세트의 효과들을 구현하는데 요구되는 DLL들은 각 효과가 사용자에 의해 현재 합성 효과에 부가될 때 컴퓨터의 메모리내에 로딩된다. 이러한 방법으로, 현재 합성 효과의 부분이 아닌 효과 모듈들에 관한 DLL들은 메모리내에 로딩되지 않으며, 그러므로 이용가능한 메모리 공간의 소모를 방지하게 된다.

발명의 개요
본 발명은 메모리를 가지는 데이터 처리 장치에 의한 합성 데이터 처리 동작이 일 세트의 가능한 데이터 처리 서브동작들로부터 선택된 서브동작들의 유향 비순환 그래프로서 사용자에 의해 어셈블리되는 데이터 처리 방법을 제공한다. 상기 방법은,

서브동작이 합성 동작에 포함하도록 사용자에 의해 선택될 때, 서브동작의 입력 및 출력 인터페이스들을 포함하는 서브동작의 파라미터들을 정의하는 서브동작 데이터를 메모리내에 로딩하고, 및

서브동작의 실행의 개시에 응답하여, 데이터 처리 장치에 의한 실행을 위해 메모리내에 서브동작 프로그램 코드를 로딩하는 단계를 포함하며,

상기 서브동작 데이터는 서브동작 프로그램 코드보다 적은 메모리 공간을 필요로 한다.

본 발명에서는, 일부 시스템들에서, 모듈이 최초로 선택될 때에 DLL들과 같은 모듈 파일들이 메모리내에 로딩되는 데이터 처리 장치들을 통해 추가적인 메모리 세이브가 달성될 수 있다. 비디오 특수 효과 시스템의 특정 예에서, 메모리내에 모듈 파일들의 로딩은 효과 동작이 사용자에 의해 선택될 때까지 뿐만아니라, 더 늦은, 즉 상기 모듈이 특수 효과 처리 동작의 일부로서 실행되어야 할 때까지 지연된다. 이것은 컴퓨터 시스템의 한정된 메모리가 가능한 최단기간동안 모듈 파일들을 저장하는데 사용되어, 메모리 공간이 그동안에 다른 사용을 위해 이용될 수 있는 것을 의미한다.

본 발명은 이것을 두 개의 스테이지들에서 모듈 파일들을 효과적으로 로딩함으로써 달성한다. 제 1 스테이지에서, 모듈 파일을 정의하며 특히 입출력(i/o) 데이터 타입들 및 기능(방법) 콜들(calls)을 규정하는 소량의 소위 "메타데이터(metadata)"가 메모리내에 로딩된다. 이것은 동작들의 시퀀스가 조리있고 문장론적으로 정확한 방법으로 형성되도록 하는데, 그 이유는 시퀀스에서 인접 모듈들의 i/o 정의들이 상기 모듈들에 대응하는 메타데이터를 이용하여 함께 매칭될 수 있기 때문이다. 제 2 스테이지에서, 실제(더 큰) DLL들은 동작들의 시퀀스를 실행하는데 최종적으로 요구될 경우에만 로딩될 필요가 있다.

본 발명의 상기 및 다른 목적, 특징 및 이점들은 다음 첨부도면을 참조하여 상세하게 설명될 것이다.

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

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

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

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

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

소프트웨어는 프로그램 코드의 두 개의 카테고리들, 즉 도 2의 좌측에 도시된 코어 프레임워크와, 도 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) 내에는 "그래프" - 실제로, 링크된 일련의 개별 특수 효과들을 가지는 "유향 비순환 그래프"가 있다. 각 효과는 이용가능해지자마자 효과의 출력을 저장하기 위한 연관된 캐시(C)를 가지는 프록시 효과(PE)로서 그래프에서 나타나며, 그로인해 예를 들면 효과들의 체인에서 더 높은 효과와 연관된 파라미터가 변화될 경우, 효과들의 체인에서 효과로부터 데이터의 재사용이 허용된다. 각 프록시 효과는 각 효과 서버(330)와 연관된다.

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

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

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

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

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

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

일반적으로, 각 COM 오브젝트는 작업 데이터가 저장되는 자체 스트림 또는 자체 기억장치에 할당될 수 있다. 그러나, 비디오 특수 효과 처리기와 같은 계층적 시스템에서, 코어(340)가 복수의 플러그-인들의 동작과 통합될 경우, 이전 시스템에 사용된 배열은 각 효과 플러그-인에 스트림을 할당한다.

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

다음의 상세한 설명에서, 여러 가지 오브젝트들 사이의 통신 프로토콜들은 도 4 및 도 5를 참조로 기술될 것이다. 코어 프로그램(340)의 그래프 편집 부분이 합성 효과를 형성하기 위하여 개별 효과들의 체인을 설정하는데 사용되는 방법이 도 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)는 코어(340)내에 "취소/재개" 오브젝트를 기록하여, 변화 전후로 파라미터의 기록(효과 서버에서)을 가리키는 처리 또는 포인터의 상세를 제공한다. 이 취소/재개 오브젝트의 수신에 응답하여, 단계 404에서 코어는 파라미터가 변화되고 일부 캐시 데이터 출력이 무효될 수 있다는 것을 모든 뷰어 윈도우에 알린다. 이 알림은 파라미터 변화가 일어나는 뷰어 윈도우에 한정되지 않는다.

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

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

단계 502에서, 뷰어 윈도우는 렌더 관리자에 리-렌더 커맨드를 송출한다. 이어서 렌더 관리자는 대응하는 효과 서버(330)에 리-렌더 커맨드를 송출한다. 효과 서버가 이미지를 리-렌더링하는 것을 완료하면, 코어(340)에 "완료" 메시지를 송출한다. 코어는 단계 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)에 접근하면, 혼합 효과 아이콘은 확대되거나 또는 확대선(710)에 의해 둘러싸여져, 보더(740)의 하부에서 두 개의 입력 포트를 도시한다. 마우스 포인터가 입력 포트중 하나에 접근하면, 그래픽 라인(720)은 그 입력 포인트 상에 스냅되고 마우스 클릭으로 소정 장소에 고정될 수 있다. 이에 의해 효과(650)와 효과(700) 사이의 논리적이고 그래픽적인 접속을 확립된다.

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

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

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

도 9는 상기 처리에 기초를 이루는 데이터 저장을 도시한다. 도 9에서 아이콘(850)은 팔레트 영역(600)내의 팔레트 아이콘(620)으로부터 그래프 편집 영역(610)으로 드래그된다

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

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

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

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

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

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

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

그래서, 효과 아이콘이 팔레트 영역으로부터 처음에 취출될 때, 종래 상기 효과에 대응하는 DLL은 메모리에 로드되어, 코어(340)에 그래프를 작성하기 위해 충분한 정보(예를 들어, 다른 효과 아이콘들과의 상호접속성)를 제공한다.

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

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

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

도 12는 이미 제안된 효과 플러그 인을 개략적으로 도시한다. 이 효과는 이미지 정보("클립"(1300)으로서 도시됨)를 취출하고, 3개의 처리 파라미터들 P1, P2 및 P3(라이트 위치 같은)에 기초하여 동작한다. 도 12의 플러그 인에서, 파라미터 값들은 플러그 인내에, 예를 들어 플러그 인의 일부로서 기록된 주문 프로그램 코드에 의해 설정된다. 이것은 예를 들어, 효과 플러그 인내에 부가적인 코드 및 종종 효과 플러그 인의 다수 버전을 필요로 하는, 파라미터들이 시간에 따라 변화하는 애니메이션 시스템 또는 조명 위치와 같은 파라미터가 움직임 트래커와 같은 다른 효과에 의해 변화되는 장치를 위해 파라미터들의 전체 제어를 한다.

도 13은 본 발명의 실시예에 따른 다른 방법을 개략적으로 도시한다. 여기서, 각 파라미터는 "메인" 효과 플러그 인(1330)에 연결된 별도의 플러그 인(1320)에 의해, 효과들 간의 링크들이 상술한 그래프 편집에서 규정되는 것과 같은 방법으로 규정된다. 실질적으로, 상술의 설명은 전체 프로세스를 간략화하고, 상기 간략화는 그 스테이지에서의 설명을 돕기 위한 것이다.

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

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

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

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

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

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

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

도 15는 시스템 캐시(1100)를 개략적으로 도시한다. 이것은 전체 캐시 영역의 개략도이다-실제적으로, 상기된 바와 같이, 캐시는 각 프록시 효과들과 연관된 복수의 개개의 캐시로 볼 수 있고, 메모리 리소스들이 그러한 개개의 캐시들 간에 동적으로 할당되기 때문에, 도 15의 표시는 유효한 것이다.

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

캐시의 의도는 방향성 비순환 그래프에서 각 효과의 렌더 출력(이것이 이미지인지 아니든)을 저장한다. 이런 방식에서, 효과가 방향성 비순환 그래프의 특정 위치에서 변경되면, 상기 위치 아래의 효과들은 새로운 출력을 제공하기 위하여 리-렌더링될 필요가 없다. 캐시된 출력들은 재사용될 수 있다. 부가적인 이익은 특정 효과들(개방된 뷰어 윈도우)의 출력을 파라미터 변화가 이루어지기 전후에 저장함으로써, 취소/재개 동작들을 도와 속도를 올리는 것이다. 대응하는 파라미터 변화도 저장되기 때문에, 파라미터 변화는 캐시 메모리(1100)로부터 적절한 재료를 로드함으로써 간단히 취소 및 재개될 수 있다. 이것은 변화가 이루어질 때 효과 서버들에 의해 기록된 취소/재개 오브젝트들의 제어하에 이루어진다.

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

실제적으로, 데이터 항목이 플러시가능(flushable)한지 아닌지를 플러그 인에 지정시키도록 할 수 있고, 이미지 데이터 항목들은 협정에 의해 플러시가능한 것으로 설정되고, 비-이미지 항목들은 플러시가능하지 않은 것으로 설정된다.

도 16은 코어(340) 및 효과 서버 사이의 비동기-동기 컨버트된 1200을 도시한다.

컨버터(1200)는 "해야할" 행렬, 즉 행해질 렌더링 작업의 리스트 형태로 렌더 관리자로부터 비동기 리-렌더링 명령들을 수신한다. 작업이 끝날 때, "끝냄" 메시지는 컨버터(1200)로부터 렌더 관리자로 리턴된다.

컨버터(1200)는 비동기 작업 요구들을 수신하고 적절한 소프트웨어 플러그 인에 동기 요구들을 발행한다. 이는 인터페이스(1200)가 제어 "스레드"(윈도우 용어)를 소프트웨어 플러그 인에 전하고, 작업이 완료될 때까지 스레드의 제어를 유지한다. 그리고나서, 소프트웨어 플러그 인은 쓰레드를 인터페이스에 리턴하고, 코어에 "끝냄" 메시지를 발행함으로써 응답한다.

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

컨버터는 코어 부분 또는 각각의 관련 플러그 인 부분으로서 구현될 수 있다.

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

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

Claims (5)

1. 메모리를 가지는 데이터 처리 장치에 의한 실행을 위해, 합성 데이터 처리 동작이 데이터 처리 서브동작들의 세트로로부터 선택된 서브동작들의 유향 비순환 그래프(directed acyclic graph)로서 사용자에 의해 어셈블리되는 데이터 처리 방법에 있어서,

   상기 합성 동작에 포함하기 위한 서브동작을 선택하는 단계;

   상기 서브동작에 대응하는 메타데이터를 상기 메모리에 로딩하는 단계로서, 상기 메타데이터는 상기 서브동작의 입력 및 출력 인터페이스들을 포함하는 서브동작의 파라미터들을 규정하고, 상기 메타데이터는 상기 합성 데이터 처리 동작을 수행하기 위해 적절한 실행 시퀀스(execution sequence)을 결정하도록 상기 데이터 처리 장치에 의해 사용되는, 상기 메타데이터 로딩 단계; 및

   상기 데이터 처리 장치에 의한 상기 서브동작의 실행을 개시하는 것에 응답하여서만 상기 서브동작에 대응하는 서브동작 프로그램 코드를 상기 메모리에 로딩하는 단계로서, 상기 메타데이터는 동일한 서브동작에 대응하는 상기 서브동작 프로그램 코드보다 적은 메모리 공간을 필요로 하는, 상기 메모리 로딩 단계를 포함하는, 데이터 처리 방법.
2. 제 1항에 있어서, 상기 서브동작들 각각은 이미지 처리 동작들을 나타내는, 데이터 처리 방법.
3. 제 1항에 있어서, 상기 서브동작 프로그램 코드는 동적 로드 라이브러리(DLL: dynamic load library) 파일로서 또는 그 파일내에 저장되는, 데이터 처리 방법.
4. 제 1항에 있어서, 상기 서브동작들에 대응하는 상기 메타데이터에 의해 규정된 상기 입력 및 출력 인터페이스들에 따라 상기 유향 비순환 그래프에서 인접한 서브동작들 사이에 데이터 전달 접속들을 개시하는 단계를 더 포함하는, 데이터 처리 방법.
5. 합성 데이터 처리 동작이 데이터 처리 서브동작들의 세트로부터 선택된 서브동작들의 유향 비순환 그래프로서 사용자에 의해 어셈블되는 데이터 처리 장치에 있어서,

   메모리;

   상기 합성 동작에 포함하기 위한 서브동작의 선택에 응답하여, 상기 서브동작에 대응하는 메타데이터를 상기 메모리에 로딩하는 제 1 로딩수단으로서, 상기 메타데이터는 상기 서브동작의 입력 및 출력 인터페이스들을 포함하는 서브동작의 파라미터들을 규정하고, 상기 메타데이터는 상기 합성 데이터 처리 동작을 수행하기 위해 적절한 실행 시퀀스를 결정하도록 상기 데이터 처리 장치에 의해 사용되는, 상기 제 1 로딩수단; 및

   상기 데이터 처리 장치에 의한 상기 서브동작의 실행을 개시하는 것에 응답하여서만 상기 서브동작에 대응하는 서브동작 프로그램 코드를 상기 메모리에 로딩하는 제 2 로딩수단으로서, 상기 메타데이터는 동일한 서브동작에 대응하는 상기 서브동작 프로그램 코드보다 적은 메모리 공간을 필요로 하는, 상기 제 2 로딩수단을 포함하는, 데이터 처리 장치.

Images