KR20070028202A - 매체 통합 계층 - Google Patents
매체 통합 계층 Download PDFInfo
- Publication number
- KR20070028202A KR20070028202A KR1020057009678A KR20057009678A KR20070028202A KR 20070028202 A KR20070028202 A KR 20070028202A KR 1020057009678 A KR1020057009678 A KR 1020057009678A KR 20057009678 A KR20057009678 A KR 20057009678A KR 20070028202 A KR20070028202 A KR 20070028202A
- Authority
- KR
- South Korea
- Prior art keywords
- visual
- function
- data
- scene graph
- data structure
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G5/00—Control arrangements or circuits for visual indicators common to cathode-ray tube indicators and other visual indicators
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T17/00—Three dimensional [3D] modelling, e.g. data description of 3D objects
- G06T17/005—Tree description, e.g. octree, quadtree
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/545—Interprogram communication where tasks reside in different layers, e.g. user- and kernel-space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T13/00—Animation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/14—Digital output to display device ; Cooperation and interconnection of the display device with other functional units
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2210/00—Indexing scheme for image generation or computer graphics
- G06T2210/08—Bandwidth reduction
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06T—IMAGE DATA PROCESSING OR GENERATION, IN GENERAL
- G06T2210/00—Indexing scheme for image generation or computer graphics
- G06T2210/61—Scene description
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/04—Changes in size, position or resolution of an image
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/04—Changes in size, position or resolution of an image
- G09G2340/0407—Resolution change, inclusive of the use of different resolutions for different screen areas
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/04—Changes in size, position or resolution of an image
- G09G2340/0407—Resolution change, inclusive of the use of different resolutions for different screen areas
- G09G2340/0414—Vertical resolution change
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/04—Changes in size, position or resolution of an image
- G09G2340/0407—Resolution change, inclusive of the use of different resolutions for different screen areas
- G09G2340/0421—Horizontal resolution change
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/04—Changes in size, position or resolution of an image
- G09G2340/0407—Resolution change, inclusive of the use of different resolutions for different screen areas
- G09G2340/0428—Gradation resolution change
-
- G—PHYSICS
- G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
- G09G—ARRANGEMENTS OR CIRCUITS FOR CONTROL OF INDICATING DEVICES USING STATIC MEANS TO PRESENT VARIABLE INFORMATION
- G09G2340/00—Aspects of display data processing
- G09G2340/04—Changes in size, position or resolution of an image
- G09G2340/0464—Positioning
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Graphics (AREA)
- Geometry (AREA)
- Computer Hardware Design (AREA)
- Human Computer Interaction (AREA)
- Processing Or Creating Images (AREA)
- Image Generation (AREA)
Abstract
애플리케이션 프로그래밍 인터페이스(API) 및 객체 모델을 포함하는 매체 통합 계층은 프로그램 코드 개발자들이 그래픽을 출력하기 위하여 장면 그래프 데이터 구조와 일관된 방식으로 인터페이스하는 것을 가능하게 해준다. 인터페이스를 통해 프로그램 코드는 자식 비주얼을 다른 비주얼에 추가하여 계층 장면 그래프를 구축하고, 형상 데이터, 이미지 데이터, 애니메이션 데이터 및 출력을 위한 기타 데이터 등의 명령 리스트를 작성하며, 비주얼에 대한 변환, 클립핑 및 불투명 속성을 지정할 수 있다. 매체 통합 계층 및 API는 프로그래머들이 정상적인 애플리케이션의 성능에 악영향을 주지 않는 방식으로 그래픽 처리 장치를 이용하면서 그들의 애프리케이션 내에 구성 효과를 간단한 방식으로 달성할 수 있게 해준다. 멀티 레벨 시스템은 상이한 매체 타입들(2D, 3D, 비디오, 오디오, 텍스트 및 이미징 등)을 결합하고 이들을 부드럽고 끊김이 없이 애니메이션화할 수 있는 능력을 포함한다.
매체 통합 계층, 애플리케이션 프로그래밍 인터페이스, 객체 모델, 장면 그래프 데이터 구조
Description
본 발명은 컴퓨터 시스템에 관한 것으로서, 보다 상세하게는 컴퓨터 시스템 상의 표시를 위한 그래픽 및 기타 비디오 정보의 처리에 관한 것이다.
컴퓨터 시스템 상에서 그래픽에 액세스하는 종래의 즉석 모드 모델(immediate mode model)은 한계에 이르고 있는데, 이것은 부분적으로는 메모리 및 버스 속도가 메인 프로세서 및/또는 그래픽 프로세서의 발달에 뒤지기 때문이다. 일반적으로, 프레임을 준비하기 위한 현재의(예를 들어 WM_PAINT) 모델은 복잡한 그래픽 효과를 원할 때 하드웨어 리프레시 속도를 따라가기에는 너무 많은 데이터 처리를 요구한다. 결과적으로, 종래의 그래픽 모델로 복잡한 그래픽 효과를 얻으려고 할 때, 다음 프레임에 대해 적시에 비주얼 효과를 인식하게 하는 변경을 완료하는 대신에, 다른 프레임들에 변경이 추가되어 시각적으로, 현저하게 바람직하지 않은 결과를 낳을 수 있다.
그래픽 출력을 제어하기 위한 새로운 모델이 본 발명의 양수인에게 양도되고 본 명세서에 참조로 편입된 미국 특허 출원 번호 10/184,795, 10/184,796, 10/185,775, 10/401,717, 10/402,322 및 10/402,268에 설명되어 있다. 이 새로운 모델은 그래픽 처리 기술에 있어서 다수의 중요한 개선점을 제공한다. 예를 들어, 미국 특허 출원 번호 10/184,795는 일반적으로 멀티플 레벨 그래픽 처리 시스템 및 방법에 관한 것으로서, 여기서 (예를 들어 운영 체계의) 하이 레벨(higher-level) 컴포넌트는 단순화된 데이터 구조 및/또는 그래픽 명령을 로우 레벨(lower-level) 컴포넌트로 전송하기 위하여 비교적 낮은 동작 속도로, 장면 그래프(scene graph)를 구축하고, 애니메이션 파라미터를 갱신하고, 장면 그래프의 데이터 구조를 트래버스하는 연산 집약적인 국면들(aspects)을 수행한다. 하이 레벨 처리는 데이터를 매우 단순화하므로, 로우 레벨 컴포넌트는 데이터를 그래픽 서브 시스템에 대한 일정한 출력 데이터로 처리하기 위해, 그래픽 서브 시스템의 프레임 리프레시 속도에 대응하는 속도와 같이, 보다 빠른 속도로(하이 레벨 컴포넌트에 비해) 동작할 수 있다. 애니메이션이 사용될 때, 변경이 있는 장면 전체를 리드로잉해야 하는 대신, 로우 레벨 처리는 필요에 따라 파라미터 구간(interval)을 보간(interpolate)하여, 렌더링시 각 프레임에 대해 약간 변경된 장면을 제공하는 순간 값(instantaneous values)을 얻음으로써 부드러운(smooth) 애니메이션을 제공할 수 있다.
미국 특허 출원 번호 10/184,796은 가변(mutable)(애니메이션화된) 값들 및 파라미터화된 그래프 컨테이너들을 제공하는 파라미터화된 장면 그래프를 설명하고 있는데, 이에 따르면 그래픽을 드로잉하기를 원하는 프로그램 코드(예를 들어 애플리케이션 프로그램 또는 운영 체계 컴포넌트)는 장면 그래프 설명의 소정의 국면들을 선택적으로 변경하면서 다른 국면들은 그대로 둘 수 있다. 프로그램 코드는 이미 구축된 장면 그래프의 부분들을 다른 파라미터와 함께 재사용할 수도 있다. 이 해할 수 있는 바와 같이, 파라미터화 및/또는 장면 그래프의 기존 부분들의 재사용을 통해, 표시된 항목들의 외관을 쉽게 변경할 수 있는 능력은 전체 그래픽 처리 효율에 있어서 상당한 이득을 제공한다.
미국 특허 출원 10/185,775는 일반적으로 장면 그래프 내에 객체 및 데이터를 통해 비주얼 정보를 저장하기 위한 캐싱 데이터 구조 및 관련 메커니즘을 설명하고 있다. 데이터 구조는 일반적으로 비주얼 정보가 어떻게 그 안에 저장되고(populate) 사용되는지를 지능적으로 제어하는 메커니즘과 관련된다. 예를 들어, 애플리케이션 프로그램에 의해 특별히 요구되지 않는 한, 데이터 구조에 저장된 정보의 대부분은 그에 대한 외부 참조(external reference)를 갖지 않는데, 이는 이러한 정보가 최적화되거나 다른 방식으로 처리될 수 있게 한다. 이해할 수 있듯이, 이것은 자원의 보존 및 효율성을 제공하며, 예를 들어 캐시 데이터 구조 내의 데이터는, 비트맵 또는 다른 후처리 결과와 같이, 보다 간단하고 그리고/또는 후속적인 반복 처리에 대한 필요를 감소시키는 다른 포맷으로 처리될 수 있다.
위의 개량들은 그래픽 처리 기술에서 상당한 이익을 제공하지만, 프로그램이 이 향상된 그래픽 모델 및 그것의 다른 관련 개선점들을 간단한 방식으로 효과적으로 이용할 수 있는 방법이 여전히 요구되고 있다. 프로그램이 개량된 그래픽 모델에 의해 제공되는 많은 기능 및 그래픽 처리 능력을 이용하여 복잡한 그래픽 및 시청각 데이터를 효율적인 방식으로 출력할 수 있게 하기 위한 포괄적이고 간단한 모델이 요구된다.
요컨대, 본 발명은 프로그래머들이 정상적인 애플리케이션 성능에 악영향을 주지 않는 방식으로 그래픽 처리 장치를 이용(leverage)하면서 그들의 애플리케이션 내의 아마도 복잡한 구성 효과(composition effect)를 간단한 방식으로 달성할 수 있게 해주는 API를 제공하는 매체 통합 계층을 제공한다. 하나의 국면은 상이한 매체 타입들(예를 들어 2D, 3D, 비디오, 오디오, 텍스트, 이미징 등)을 결합하여 이들을 유연하고 끊김이 없이 함께 애니메이션화할 수 있는 능력을 제공한다.
MIL은 멀티 스테이지 구성을 위한 그래픽 아키텍처와, 프로그램 및 스크립트 인터페이스에서의 기능적 패리티(functional parity)를 가능케 하는 프로그래밍 모델을 제공한다. API 및 스크립트는 유지 구조(retained structure) 또는 장면 설명(scene description)의 생성을 가능하게 하는데, 이는 렌더링시 구성되지만 즉시-모드(immediate-mode) 속성을 더욱 갖는 영역들을 포함한다.
MIL은 인터페이스들을 통해 비주얼 정보를 저장하기 위한 데이터 구조에 대한 액세스를 제공하며, 이에 따라 애플리케이션은 컴퓨터 하드웨어에 의해 제공되는 그래픽 능력을 이용할 수 있게 된다. 인터페이스는 요소 객체 모델(element object model) 및, 프로그램 코드 개발자들이 그래픽을 생성하기 위하여 장면 그래프 데이터 구조와 일정하게 인터페이싱할 수 있게 하는 방식으로 그 요소 객체 모델을 이용하기 위한 벡터 그래픽 마크업 언어(vector graphics markup language)를 지원한다. 데이터 구조는 직접 렌더링에 사용되거나, 고속 구성 및 애니메이션을 위해 로우 레벨 그래픽 시스템에 제공될 수 있도록 비주얼 정보를 "컴파일링"하는 데 사용될 수도 있다.
벡터 그래픽 요소 객체 모델은 일반적으로 모양(shape) 요소 및, 장면 그래프의 장면 그래프 객체 모델과 상관하는(correlate) 이미지 및 비디오 요소를 포함하는 다른 요소에 대응한다. 마크업은 장면 그래프 데이터 구조의 객체들로 변환(translate)되는 요소 트리 내의 요소들을 포함하는 데이터로 분해(parse)될 수 있다. 다른 마크업은 장면 그래프 객체를 생성하는 데이터 및 호출로 직접 변환될 수 있다. 마크업 언어는, 명명될 수 있으며 마크업 내의 다른 위치에서 재사용을 가능하게 하는, 단순 스트링 포맷 또는 복합 속성 신택스를 포함하는 요소를 설명하는 다른 방법들을 제공한다.
MIL의 일 국면은 API 세트를 통한 애니메이션 및 타이밍의 통합으로서, 애니메이션을 고유한 기본 레벨 개념(inherent base-level concept)으로서 제공한다. 애니메이션을 더욱 유연하게 하기 위하여, MIL은 멀티 레벨 그래픽 처리 시스템 및 방법(예를 들어 운영 체계의)을 제공한다. 하나의 그러한 멀티 레벨 그래픽 처리 시스템은, 틱-온-디맨드(tick-on-demand)나 슬로우 틱 하이 레벨 컴포넌트, 및 (예컨대 그래픽 하드웨어 프레임 리프레시 속도에서의) 패스트 틱 로우 레벨 컴포넌트를 포함하는 2개의 컴포넌트를 포함한다. 일반적으로, 하이 레벨 저주파(less frequent) 컴포넌트는 단순화된 데이터 구조를 로우 레벨 컴포넌트로 전송하기 위하여 애니메이션 파라미터를 갱신하고 장면 데이터 구조를 트래버스하는 연산 집약적 국면들을 수행한다. 로우 레벨 컴포넌트는 데이터 구조를 그래픽 서브 시스템에 대하여 일정한 출력 데이터로 처리하기 위하여 그래픽 서브 시스템의 프레임 리프레시 속도와 같은 보다 높은 주파수로 동작한다. 로우 레벨 처리는 필요에 따라 임의의 파라미터 구간을 보간하여 애니메이션의 각 프레임에 대한 장면을 렌더링하기 위한 순간 값을 얻는 것을 포함한다.
최상위 레벨(top level) MIL 객체는 드로잉될 메인 콘텐츠를 포함하는 객체인 비주얼 트리를 포함한다. 제어는 트리의 비주얼들로부터 직접 도출된다. 비주얼들은 장치 및 부모 컨텍스트에 대해 독립적(device and parent context independent)이다. 렌더링 타겟은 비주얼이 드로잉되는 장치이다. 이 객체(예를 들어 스크린)는 그 자신의 오염(dirty) 또는 무효화(invalidation) 메커니즘을 가질 수 있다. 다양한 렌더링 타겟은 윈도우 내의 스크린, 프린터, 메타파일, 표면, 스트리밍 매체 파일(예를 들어 DVD) 및 장면의 나머지 부분으로부터 분리되어 드로잉되는 장면의 일부인 "서브 윈도우"를 포함한다. 다른 드로잉 관련 객체들은 렌더링 타겟 상에 비주얼 트리를 드로잉하도록 구성된 객체를 포함하는 비주얼 렌더러와, 렌더링 타겟 상에 언제 비주얼 트리를 드로잉할지를 아는 디스플레이 스케쥴러 객체를 포함한다. 시간 관리자는 타이밍 노드들의 세트에 대한 컨텍스트 객체이며, 스케쥴러가 시간 체크(tick on)를 호출하는 객체이다.
본질적으로 매체 통합 계층을 통한 드로잉의 시작점인 비주얼 API가 제공되며, 이는 비주얼 트리를 매체에 접속시키는 비주얼 관리자 객체를 포함하는 많은 타입의 객체를 포함한다. 상이한 타입의 비주얼 관리자들(예를 들어, 스크린, 프린터 및 표면(Surface))은 그들의 특정 매체로의 비주얼 트리의 렌더링을 담당한다. 비주얼은 프로그래머가 드로잉을 행하는 곳이며, 비주얼 트리 내의 한 노드이고, 프로그램이 드로잉할 장소를 제공한다.
드로잉 컨텍스트 API는 비주얼에 저장되거나 이미지 데이터로 렌더링되는 비주얼 콘텐츠를 어떻게 구성할 것인지에 대한 컨텍스트 기반 프로그래밍 모델을 제공한다. 드로잉 컨텍스트를 획득하고, 유지 비주얼/드로잉 비주얼 내에 비주얼 콘텐츠를 열거하는 데 필요한 클래스들 및 입력점들(entry points)은 물론 드로잉 컨텍스트 클래스들이 제공된다.
가변성(mutability)을 가능하게 하기 위하여, 공통 가변 기본 클래스로부터 도출되는 타입들의 단일 세트가 제공된다. 가변성이 변경하기를 원하는 임의의 타입은 가변 클래스로부터 도출될 수 있다. 예를 들어, 그래픽 프로그래밍에 있어서, 객체 모델은 브러시, 펜, 형상(geometry), 부동 애니메이션(FloatAnimation), 그래디언트 스톱(GradientStop), 세그먼트 등을 포함한다. IsChangeable 속성은 가변 객체가 상태를 정의하는 그의 현재 값에 따라 수정될 수 있는지의 여부를 규정한다.
브러시는 평면을 채우는 방법을 표현하는 객체이다. 절대적인 방법으로 평면을 채울 수 있는 것 외에도, 매체 통합 계층의 브러시들은 이들이 채우고 있는 객체의 크기에 대비해 평면을 채우는 방법을 이용할 수도 있다. 브러시 타입의 예는 솔리드 칼라 브러시, 비주얼 브러시(벡터 그래픽 자원/비주얼을 참조할 수 있다), 드로잉 브러시, 리니어 그래디언트, 래디컬 그래디언트, 이미지 브러시 및 나인 그리드 브러시(NineGridBrush)를 포함한다. 소정의 브러시 객체들은 이들이 사용될 때 좌표 시스템과 관련되는 방법에 대한 아이디어, 및 이들이 사용되는 형상의 경계 박스(bounding box)와 관련되는 방법에 대한 아이디어를 갖는다. 이 크기는 브러시가 채우고 있는 객체에 기초한다. 소정 타입의 브러시들(예를 들어 비주얼 브러시)은 프로그래머 정의 패턴을 생성하도록 타일화될 수도 있다. 브러시 기본 클래스(Brush base class)는 변환(Transform), 일반 불투명(general opacity), 및 혼합(blend) 모드를 갖는다. 브러시(및 벡터 그래픽 및 MIL API 내의 다른 객체 자원들) 객체들은 가변(Changeable)이며, 생성된 후에 기록 가능하고, 이들이 적격 이용(qualified use)으로 사용된 후 어떻게 행동하는지에 대해서는 일반 가변 패턴을 따른다.
객체들의 형상 클래스(Geometry class)는 펜 및 브러시를 가진 2D 벡터 기반 데이터의 클립핑, 히트 테스팅(hit-testing), 및 렌더링에 사용될 수 있다. 도출된 형상 클래스는 보다 특정적인 구축 및 목록 시맨틱(building and enumeration semantic)을 제공한다. 보다 복잡한 모양의 형상의 명시적 정의를 허용하는 일반화된 경로 형상(PathGeometry)은 물론 다수의 모양 특정(shape-specific) 형상 타입이 제공된다. 형상은 추상 기본 클래스(abstract base class)이다. 형상 집합은 다수의 형상 객체의 정의된 영역에 대한 특정 결합 모드(CombineMode) 동작을 이용하여 결합된 다수의 형상 객체의 집합이다. 이 객체는 경로 형상 내의 경로도 객체들을 엄격하게 이용하여 할 수 있는 것보다 형상 객체들의 비주얼 결합을 보다 쉽게 가능하게 한다.
이미지 소스(ImageSource)는 이미징을 위한 기본 빌딩 블록을 포함하는 추상 클래스이다. 이미지 소스는 단일의 일정한 픽셀들의 세트를 소정의 크기 및 해상도로 개념적으로 표현한다. 예를 들어, 이미지 소스는 디코더가 제공할 수 있는 이미지 파일 내의 단일 프레임이거나, 그 자신의 소정의 이미지 소스 상에서 동작하는 변환의 결과일 수 있다. 이미지 소스는 가변적인데, 이는 그 자신의 속성이 변경될 수 있기 때문이 아니라 그의 서브 클래스의 속성이 잠재적으로 변경될 수 있기 때문이다.
객체들의 변환 클래스(Transform class)는 벡터 및 래스터 그래픽의 스케일링, 회전, 이동 및 왜곡(skewing)을 위해 제공된다. 도출된 변환 클래스는 사용 및 목록 시맨틱을 제공한다.
효과(Effects)는 장면의 비주얼 콘텐츠를 렌더링 중심 방식으로 변경하는 수단을 제공한다. 예를 들어, 이미지 효과(래스터 기반 비트맵 효과)는 장면 일부의, 이미지-기반의, 완전히 구성된 표현 상에 동작한다. 효과는 이미지 효과(ImageEffect), 혼합 모드(BlendMode) 및 벡터 효과(VectorEffect)를 포함하는 다양한 타입으로 나뉜다. 이미지 효과는 서브 그래프 또는 요소에 적용됨으로써 유지 모드 장면에 사용되거나, 독립 이미지 파이프라인(standalone image pipeline)에 사용될 수 있다. 혼합 모드는 이미지 기반 효과의 특정 형태이며, 일반적으로 이미지 효과와 동일한 방식으로 유지 모드 장면에 적용될 수 있다. 혼합 모드는 소스가 구성될 때 소스 및 목적 칼라의 조합을 수행하는데, 예를 들어 곱하거나 더한다.
히트 테스팅은 장면에서 비주얼들을 선택하는 데 사용되며, 제어 트리의 최상부에서 시작하여 점 또는 형상에 의해 제어 또는 제어 세트를 리턴(return)함으로써 동작한다. 제어는 렌더링 형상, 경계 박스, 대역외 형상(out-of-band geometry)(히트 영역), 이미지 불투명 또는 마스크 및 그 자신의 로직을 포함하는 지원 서비스들과 맞는지(hit) 아닌지의 여부를 정의할 수 있다. 제어는 히트 시 특정 히트 관련 데이터를 리턴할 수 있다. 히트 테스트 메커니즘은 히트 테스트 결과를 효율적인 방식으로 필터링할 수 있다. 히트 테스트 워크(hit test walk)는 비주얼 트리의 심층(deep) 우에서 좌로의 워크이며, 히트는 z-오더 상하 방식으로 재호출(callback)을 통해 보고된다. 내려갈 때, 히트 테스터는, 예를 들어 모양을 가진 캔버스 또는 내부 캔버스를 가진 도크 패널(dock panel) 등의 요소 레벨 관계에 의해 필터링을 관측(view)한다. 히트가 발생할 때, 히트 테스터는 추가 히트(있을 경우)의 처리를 계속하거나 중지할 수 있다.
타이밍 제어 엔진 및 한 세트의 애니메이션 객체들을 포함하는 애니메이션 시스템이 제공된다. 타이밍 엔진은 시간에 따라 변하는 행동(behavior)을 나타내는, 예를 들어 애니메이션 및 오디오 또는 비디오 매체 객체 등의 임의의 객체들에 의해 사용될 수 있는 서비스이다. 애니메이션 객체는 시간 간격을 다른 데이터 타입으로 맵핑하는 한 세트의 함수를 구현하며, 이 다른 데이터 타입들은 다른 하이 레벨 객체들로의 입력으로 사용된다. 그래픽 애니메이션은 애니메이션 집합을 렌더링 동작과 연관시킴으로써 달성된다. 렌더링 동작에 사용되는 각각의 애니메이션은 소위 "타임라인"으로 지칭되는 개별 클록 상에서 실행될 수 있다. 다수의 타임라인이 계층적 타이밍을 지원하도록 타이밍 트리 내에 구성될 수 있다. 애니메이션화된 원시 함수가 드로잉되고, 애니메이션 파라미터가 지정되면, 로우 레벨 렌더링 시스템은 규칙적인 간격으로 장면의 리드로잉을 관리한다. 프레임이 렌더링될 때마다, 장면 내에 포함된 애니메이션의 현재 값이 경과 시간(대부분의 경우 시스템 클록에 의해 측정된다)에 기초하여 계산된 후, 애니메이션화된 원시 함수가 리드로잉된다.
다양한 원시 함수 타입, 칼라 기능 및 매체 지원이 또한 MIL을 통해 제공된다. 매체 데이터(MediaData)는 임의의 오디오/비디오 콘텐츠를 재생하는 데 사용될 수 있다.
다른 이익 및 이점들은 첨부된 도면들과 관련하여 취해질 때 아래의 상세하나 설명으로부터 명백해질 것이다.
도 1은 본 발명이 구현될 수 있는 예시적인 컴퓨터 시스템을 나타내는 블록도이다.
도 2는 본 발명이 구현될 수 있는 그래픽 계층 아키텍처를 나타내는 블록도이다.
도 3은 본 발명의 일 국면에 따라, 이를테면 장면 그래프를 트래버스하여 그래픽 명령어 및 다른 데이터를 제공함으로써 장면 그래프를 처리하기 위한 비주얼 들 및 관련 컴포넌트들의 장면 그래프의 표현이다.
도 4는 본 발명의 일 국면에 따라 구성된 검증 비주얼, 드로잉 비주얼 및 관련 명령어 리스트의 장면 그래프의 표현이다.
도 5는 본 발명의 일 국면에 따른 객체 모델의, 비주얼 클래스의 표현이다.
도 6은 본 발명의 일 국면에 따른 객체 모델의 다양한 다른 객체들의 표현이 다.
도 7은 본 발명의 일 국면에 따른 변환 클래스 계층 구조의 표현이다.
도 8 및 9는 각각 본 발명의 일 국면에 따른 형상 스케일 및 불균일 스케일로의 비주얼의 데이터의 변환의 표현이다.
도 10은 본 발명의 일 국면에 따른 객체 모델의 형상 클래스의 표현이다.
도 11은 본 발명의 일 국면에 따른 경로 형상 구조의 표현이다.
도 12는 본 발명의 일 국면에 따라 원시 함수에 의해 생성되는 그래픽의 예를 나타내는 비주얼 및 명령어 리스트의 장면 그래프의 표현이다.
도 13은 본 발명의 일 국면에 따른 객체 모델의 브러시 클래스의 표현이다.
도 14는 본 발명의 일 국면에 따라 타입의 가변성을 제어하기 위해 상태 머신에 의해 요구가 처리되는 가변 아키텍처를 나타내는 블록도이다.
도 15-17은 본 발명의 일 국면에 따라 속성 상태가 어떻게 가변 타입들의 행동을 제어하는지를 나타내는 상태도이다.
도 18-23은 본 발명의 일 국면에 따라 속성들이 어떻게 예시 코드에 대한 상태 전이 및 복제 행동을 제어하는지를 나타내는 예시 장면 그래프 내의 객체들의 계층적 표현이다.
도 24는 본 발명의 일 국면에 따라 리니어 그래디언트 브러시 객체 내의 데이터로부터 유래되는 렌더링된 그래픽의 표현이다.
도 25는 본 발명의 일 국면에 따라 래디컬 그래디언트 브러시 객체 내의 데이터로부터 유래되는 렌더링된 그래픽의 표현이다.
도 26은 본 발명의 일 국면에 따라 다양한 스트레치 값을 가진 데이터로부터 유래되는 렌더링된 그래픽의 표현이다.
도 27은 본 발명의 일 국면에 따라 다양한 타일 값을 가진 데이터로부터 유래되는 렌더링된 그래픽의 표현이다.
도 28은 본 발명의 일 국면에 따른 렌더링된 나인 그리드 브러시 객체의 표현이다.
도 29-40은 본 발명의 일 국면에 따라 애니메이션에 사용되는 예시 타임라인들의 그래픽 표현이다.
도 41은 본 발명의 일 국면에 따라 3차원 비주얼을 통해 구성되는 예시 3차원 이미지의 표현이다.
도 42는 본 발명의 일 국면에 따라 3차원 지원을 제공하는 3차원 개념들의 표현이다.
예시적인 동작 환경
도 1은 본 발명이 구현될 수 있는 적절한 컴퓨팅 시스템 환경(100)의 예를 나타낸다. 컴퓨팅 시스템 환경(100)은 단지 적절한 컴퓨팅 환경의 일 예이며 본 발명의 사용 또는 기능의 범위에 제한을 가하도록 의도된 것은 아니다. 컴퓨팅 환경(100)은 예시적인 동작 환경(100)에 도시된 컴포넌트들 중의 임의의 하나 또는 조합에 관하여 임의의 종속성(dependency) 또는 요구사항(requirement)을 갖는 것으로 해석되어서는 안된다.
본 발명은 많은 다른 범용 또는 특수목적 컴퓨팅 시스템 환경들 또는 구성들과 함께 동작될 수 있다. 본 발명과 함께 사용하기에 적합할 수 있는 잘 알려진 컴퓨팅 시스템, 환경, 및/또는 구성의 예로는, 퍼스널 컴퓨터, 서버 컴퓨터, 핸드헬드(hand-held) 또는 랩탑 장치, 멀티프로세서 시스템, 마이크로프로세서-기반 시스템, 셋 탑 박스(set top box), 프로그램가능 가전제품(programmable consumer electronics), 네트워크 PC, 미니컴퓨터, 메인프레임 컴퓨터, 상기의 시스템 또는 장치 중의 임의의 것을 포함하는 분산형 컴퓨팅 환경 등이 포함될 수 있지만, 이에 한정되지 않는다.
본 발명은 컴퓨터에 의해 실행되는, 프로그램 모듈과 같은 컴퓨터 실행가능 명령과 일반적으로 관련하여 기술될 수 있다. 일반적으로, 프로그램 모듈은 특정 태스크를 수행하거나 특정 추상 데이터 유형을 구현하는 루틴, 프로그램, 오브젝트, 컴포넌트, 데이터 구조 등을 포함한다. 본 발명은 또한 통신 네트워크 또는 다른 데이터 전송 매체를 통해 링크된 원격 프로세싱 장치에 의해 태스크를 수행하는 분산형 컴퓨팅 환경에서 실행될 수 있다. 분산 컴퓨팅 환경에서, 프로그램 모듈 및 그외 데이터는 메모리 저장 장치를 포함하는 국부 및 원격 컴퓨터 저장 매체 내에 위치할 수 있다.
도 1을 참조하면, 본 발명을 구현하기 위한 예시적인 시스템은 컴퓨터(110)의 형태의 범용 컴퓨팅 장치를 포함한다. 컴퓨터(110)의 컴포넌트들로는, 프로세싱 유닛(120), 시스템 메모리(130), 및 시스템 메모리를 포함하는 다양한 시스템 컴포넌트를 프로세싱 유닛(120)에 연결시키는 시스템 버스(121)가 포함될 수 있지 만, 이에 한정되는 것은 아니다. 시스템 버스(121)는 다양한 버스 아키텍처 중의 임의의 것을 사용하는 로컬 버스, 주변 버스, 및 메모리 버스 또는 메모리 컨트롤러를 포함하는 몇가지 유형의 버스 구조 중의 임의의 것일 수 있다. 예로서, 이러한 아키텍처는 산업 표준 아키텍처(ISA) 버스, 마이크로 채널 아키텍처(MCA) 버스, 인핸스드 ISA(Enhanced ISA; EISA) 버스, 비디오 일렉트로닉스 표준 어소시에이션(VESA) 로컬 버스, 가속 그래픽 포트(AGP) 버스 및 메자닌(Mezzanine) 버스로도 알려진 주변 컴포넌트 상호접속(PCI) 버스를 포함하지만, 이에 한정되는 것은 아니다.
컴퓨터(110)는 통상적으로 다양한 컴퓨터 판독가능 매체를 포함한다. 컴퓨터 판독가능 매체는 컴퓨터(110)에 의해 액세스될 수 있는 임의의 이용가능한 매체일 수 있으며, 휘발성 및 비휘발성 매체, 분리형(removable) 및 비분리형(non-removable) 매체를 둘다 포함한다. 예로서, 컴퓨터 판독가능 매체는 컴퓨터 저장 매체 및 통신 매체를 포함할 수 있지만, 이에 한정되는 것은 아니다. 컴퓨터 저장 매체는 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 또는 다른 데이터와 같은 정보의 저장을 위한 임의의 방법 또는 기술로 구현되는 휘발성 및 비휘발성, 분리형 및 비분리형 매체를 둘다 포함한다. 컴퓨터 저장 매체는 RAM, ROM, EEPROM, 플래쉬 메모리 또는 기타 메모리 기술, CD-ROM, DVD(digital versatile disk) 또는 기타 광학 디스크 저장장치, 자기 카세트, 자기 테이프, 자기 디스크 저장장치 또는 기타 자기 저장장치, 또는 컴퓨터(110)에 의해 액세스될 수 있고 원하는 정보를 저장하는 데 사용될 수 있는 임의의 기타 매체를 포함할 수 있지만, 이에 한정되지 않는다. 통신 매체는 통상적으로 반송파 또는 기타 전송 메커니즘 등의 변조된 데이터 신호에 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈, 또는 다른 데이터를 구현하며, 임의의 정보 전달 매체를 포함한다. "변조된 데이터 신호"라는 용어는 신호 내에 정보를 인코딩하도록 설정되거나 변환된 속성을 하나 또는 그 이상을 갖는 신호를 의미한다. 예로서, 통신 매체는 유선 네트워크 또는 직접 유선 접속 등의 유선 매체와, 음향, RF, 적외선 및 기타 무선 매체 등의 무선 매체를 포함하지만, 이에 한정되지 않는다. 상술한 것들 중의의 임의의 조합이 컴퓨터 판독가능 매체의 범위 내에 포함되어야 한다.
시스템 메모리(130)는 ROM(131) 및 RAM(132) 등의 휘발성 및/또는 비휘발성 메모리의 형태의 컴퓨터 저장 매체를 포함한다. 시동중과 같은 때에 컴퓨터(110) 내의 구성요소들간에 정보를 전송하는 것을 돕는 기본 루틴을 포함하는 기본 입출력 시스템(133; BIOS)은 일반적으로 ROM(131)에 저장된다. RAM(132)은 일반적으로 프로세싱 유닛(120)에 즉시 액세스될 수 있고 및/또는 프로세싱 유닛(120)에 의해 현재 작동되는 프로그램 모듈 및/또는 데이터를 포함한다. 예로서, (한정하고자 하는 것은 아님) 도 1은 운영 체계(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)를 도시한다.
컴퓨터(110)는 또한 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체를 포함할 수 있다. 단지 예로서, 도 1에는 비분리형 비휘발성 자기 매체로부터 판독하거나 그 자기 매체에 기록하는 하드 디스크 드라이브(140), 분리형 비휘발성 자기 디스크(152)로부터 판독하거나 그 자기 디스크에 기록하는 자기 디스크 드라 이브(151), 및 CD-ROM 또는 기타 광학 매체 등의 분리형 비휘발성 광학 디스크(156)로부터 판독하거나 그 광학 디스크에 기록하는 광학 디스크 드라이브(155)가 도시되어 있다. 예시적인 동작 환경에서 사용될 수 있는 다른 분리형/비분리형, 휘발성/비휘발성 컴퓨터 저장 매체는 자기 테이프 카세트, 플래쉬 메모리 카드, DVD(Digital versatile disk), 디지털 비디오 테이프, 고체 RAM, 고체 ROM 등을 포함하지만 이에 한정되지 않는다. 하드 디스크 드라이브(141)는 일반적으로 인터페이스(140)와 같은 비분리형 메모리 인터페이스를 통해 시스템 버스(121)에 접속되고, 자기 디스크 드라이브(151) 및 광학 디스크 드라이브(155)는 일반적으로 인터페이스(150)와 같은 분리형 메모리 인터페이스에 의해 시스템 버스(121)에 접속된다.
앞서 기술되고 도 1에 도시된 드라이브 및 그 관련 컴퓨터 저장 매체는 컴퓨터(110)를 위한 컴퓨터 판독가능 명령, 데이터 구조, 프로그램 모듈 및 기타 데이터의 저장을 제공한다. 도 1에서, 예를 들어, 하드 디스크 드라이브(141)는 운영 체계(144), 애플리케이션 프로그램(145), 기타 프로그램 모듈(146), 및 프로그램 데이터(147)를 저장하는 것으로 도시된다. 이들 컴포넌트는 운영 체계(134), 애플리케이션 프로그램(135), 기타 프로그램 모듈(136), 및 프로그램 데이터(137)와 동일할 수도 있고 다를 수도 있다. 운영 체계(144), 애플리케이션 프로그램(145), 다른 프로그램 모듈(146), 및 프로그램 데이터(147)는 최소한 다른 복사본(different copies)임을 나타내기 위하여 다른 번호를 부여하였다. 사용자는 일반적으로 마우스, 트랙볼, 또는 터치 패드라 불리우는 포인팅 장치(161), 키보드 (162), 마이크로폰(163), 타블렛(전자 디지타이저; 164)와 같은 입력 장치를 통해 컴퓨터(110)에 명령 및 정보를 입력할 수 있다. (도시되지 않은) 기타 입력 장치는 조이스틱, 게임 패드, 위성 안테나, 스캐너 등을 포함할 수 있다. 이들 입력 장치 및 그외의 입력 장치는 시스템 버스에 연결된 사용자 입력 인터페이스(160)를 통해 종종 프로세싱 유닛(120)에 접속되지만, 병렬 포트, 게임 포트 또는 유니버설 시리얼 포트(USB) 와 같은 기타 인터페이스 및 버스 구조에 의해 접속될 수 있다. 모니터(191) 또는 다른 유형의 디스플레이 장치는 또한 비디오 인터페이스(190) 등의 인터페이스를 통해 시스템 버스(121)에 접속된다. 모니터(191)는 또한 터치 스크린 인터페이스(192)와 같은 인터페이스를 통해 컴퓨터 시스템(110)에 핸드라이팅과 같은 디지탈 입력을 입력할 수 있는 터치 스크린 패널(193) 등에 통합될 수 있다. 모니터 및/또는 터치 스크린 패널은, 터치 스크린 패널(193)이 본질적으로 태블릿(164)으로서 기능하는 태블릿 타입의 개인용 컴퓨터에서와 같이, 컴퓨팅 장치(110)가 합체된 하우징에 물리적으로 결합될 수 있다는 점에 유의하자. 추가적으로, 컴퓨터는 또한 출력 주변 인터페이스(194) 등을 통해 접속될 수 있는 스피커(195) 및 프린터(196) 등의 기타 주변 출력 장치를 포함할 수 있다.
컴퓨터(110)는 원격 컴퓨터(180)와 같은 하나 이상의 원격 컴퓨터로의 논리적 접속을 이용한 네트워크 환경에서 동작할 수 있다. 원격 컴퓨터(180)는 퍼스널 컴퓨터, 서버, 라우터, 네트워크 PC, 피어(peer) 장치, 또는 기타 공통 네트워크 노드일 수 있으며, 비록 도 1 에는 메모리 저장 장치(181)만이 도시되어 있지만, 컴퓨터(110)에 관하여 상술한 구성요소 중 다수 또는 모든 구성요소를 일반적으로 포함할 수 있다. 도시된 논리적 접속은 근거리 통신망(LAN; 171) 및 원거리 통신망(WAN; 173)을 포함하지만, 그 외의 네트워크를 포함할 수도 있다. 이러한 네트워크 환경은 사무실, 기업 광역 컴퓨터 네트워크(enterprise-wide computer network), 인트라넷, 및 인터넷에서 일반적인 것이다.
LAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 네트워크 인터페이스 또는 어댑터(170)를 통해 LAN(171)에 접속된다. WAN 네트워크 환경에서 사용되는 경우, 컴퓨터(110)는 일반적으로 인터넷 등의 WAN(173)을 통해 통신을 구축하기 위한 모뎀(172) 또는 기타 수단을 포함한다. 내장형 또는 외장형일 수 있는 모뎀(172)은 사용자 입력 인터페이스(160) 또는 기타 적절한 메커니즘을 통해 시스템 버스(121)에 접속될 수 있다. 네트워크 환경에서, 컴퓨터(110)에 관하여 도시된 프로그램 모듈 또는 그 일부분은 원격 메모리 저장 장치에 저장될 수 있다. 예로서 (한정하고자 하는 것은 아님), 도 1은 메모리 장치(181)에 상주하는 원격 애플리케이션 프로그램(185)을 도시한다. 도시된 네트워크 접속은 예시적인 것이며, 컴퓨터들간의 통신 링크를 구축하는 그 외의 수단이 사용될 수 있다.
매체 통합 계층(MIL)
본 발명의 일 국면은 일반적으로 즉석 모드 그래픽 애플리케이션 프로그래밍 인터페이스(API), 드로잉 명령들, 한 세트의 제어 레벨 객체들, 및 마크업 언어를 캐시하는 역할을 하는 스크린 분할 데이터 구조 및 API를 포함하는 매체 통합 계층(MIL)으로 지칭되는 아키텍처에 관한 것이다. 일반적으로, 이 아키텍처는 시스템 디스플레이 상에서 그래픽 출력을 렌더링하기 위하여 애플리케이션 또는 운영 체계 컴포넌트와 같은 프로그램 코드가 드로잉 명령 및 다른 정보(예를 들어 이미지 비트맵)를 그래픽 컴포넌트로 전송할 수 있게 한다. 본 발명의 일 국면은, 프로그램들이 데이터 구조, 명령어 리스트(드로잉 원시 함수(primitives)/명령어) 및 다른 그래픽 관련 데이터로 장면 그래프를 채우는 것을 가능하게 하는, 예를 들어 API 형태의 다수의 정의된 함수 및 메소드를 객체 모델에 제공한다. 처리시 장면 그래프는 그래픽을 스크린 상에 표시한다.
본 발명의 일 국면에 따르면, MIL은 계층들에서 동작하는 복합 시스템(composited system)이다. 합성(composite)될 각 항목은 풀 알파 채널을 가진 비트맵 내에 개념적으로 드로잉된다. 이어서, 알파 채널은 비트맵을 백 버퍼(back buffer)로 합성할 때 사용된다. 개별 객체들은 백(back)으로부터 프론트로 합성된다. 이것은 개념적인 모델이지만, 실제로 시스템은 언제 풀 중간 비트맵 표면이 필요하지 않은지를 알고 백 버퍼 또는 다른 백 표면으로 직접 합성한다는 점에 유의하자. 시스템은 또한 증가 변화를 이해하고 최소의 리페인트(repaint)를 행할 수 있다.
도 2는 본 발명이 구현될 수 있는 일반적인 계층 아키텍처(MIL; 200)를 나타낸다. 도 2에 나타난 바와 같이, 프로그램 코드(202)(예를 들어, 애플리케이션 프로그램 또는 운영 체계 컴포넌트 등)는 이미징(204)을 통해, 벡터 그래픽 요소들(206)을 통해, 그리고/또는 비주얼 애플리케이션 프로그래밍 인터페이스(API) 계층(212)으로 직접 배치되는 함수/메소드 호출을 통하는 등등 하나 이상의 다양한 방 법으로 그래픽 데이터를 출력하도록 개발될 수 있다. 일반적으로, 이미징(204)은 프로그램 코드(202)에 이미지, 예를 들어 비트맵을 로딩, 편집 및 저장하기 위한 메커니즘을 제공한다. 후술되는 바와 같이, 이미지는 시스템의 다른 부분에 의해 사용될 수 있으며, 원시 함수 드로잉 코드를 사용하여 이미지로 직접 드로잉하는 방법도 있다. 벡터 그래픽 요소들(206)은 객체 모델의 나머지와 일관된 그래픽을 드로잉하는 다른 방법을 제공한다(후술됨). 벡터 그래픽 요소(206)는 마크업 언어를 통해 생성될 수 있으며, 요소/속성 시스템(208) 및 레이아웃 시스템(210)은 비주얼 API 계층(212)에 대한 적절한 호출을 행하기 위해 벡터 그래픽 요소를 해석한다. 벡터 그래픽 요소(206)는 요소/속성 시스템(208) 및 레이아웃 시스템(210)과 함께 전술한 특허 출원 번호 10/401,717에 설명되어 있다.
따라서, MIL(200)은 프로그래머가 이미지를 로딩, 편집 및 저장하기 위한 파이프라인인 이미징(204) 등으로 프로그래밍할 수 있는 상이한 레벨들을 포함한다. 이미지는 필요에 따라 시스템의 나머지에서 사용될 수 있다. 더욱이, 원시 함수 드로잉 코드를 사용하여 이미지로 직접 드로잉하는 방법이 있다.
또 하나의 레벨은 드로잉될 항목들을 체계화하기 위한 데이터 구조(216)에 대한 액세스를 주로 제공하는 API인 비주얼 API(212)를 포함한다. 항목들 각각은 시스템에 의해 캐싱될 수 있는 드로잉 명령들에 의해 로딩될 수 있다. 이러한 데이터 구조 및 드로잉되는 것을 지정하는 다양한 방법이 있는데, 일반적인 MIL 인식 애플리케이션의 내부에서 이러한 API는 레이아웃 시스템(210) 내로부터 사용될 수 있다.
프로그래밍의 제3 레벨은, 제어/요소 객체 모델의 나머지와 일관된 방법으로 그래픽을 설명하고 드로잉하는 마크업 언어인 벡터 그래픽 요소 레벨(206)을 포함한다. 벡터 그래픽 요소는 요소 시스템을 통해 그래픽 시스템을 노출시킨다. 이것은 렌더링을 위한 한 세트의 요소들 및 어느 임의의 요소 상에서도 동작하는 한 세트의 속성들을 포함한다. 일 실시예에서는, 요소들로 분해되고 요소들을 생성하는 요소 레벨 벡터 그래픽, 및 효율적인 방식으로 분해되고 저장되는 자원 레벨 객체 모델을 포함하는 2개의 서브세트가 있다. 요소 레벨 객체 모델은 요소 트리, 속성 시스템 및 레이아웃 시스템(210)을 끌어들이는 하이 레벨 제어 세계에서 동작하는 것을 지칭한다. 분해(parcing)와 관련하여, 요소 레벨의 많은 동적 속성들은 MIL 타입이다. 일반적으로, 마크업은 객체들로 분해(resolve)되며, 마크업 파일의 최상부에서 XAML 마크업에 대한 XML 스킴이 대개 다음과 같이 선언된다:
예를 들어, <Path> 태그가 사용될 때, 파서는 스키마를 이용하여 관련 네임 스페이스(예를 들어 System.Windows.Shapes)를 탐색함으로서 객체를 분해하고 구축 한다. 전술한 미국 특허 출원 번호 10/401,717에 전반적으로 설명되어 있는 바와 같이, 파서는 스트링을 MIL 객체의 인스턴스로 변환하기 위해 타입 변환기에 의존한다. 복잡한 신택스(syntax)를 요구하는 이러한 타입들은 동적 속성과 동일한 방식으로 분해되는 선택적인 XML 속성으로서 노출된 각각의 기록 가능 CLR(commmon language runtime; 공통 언어 실행시간) 속성을 갖는다. 몇몇 타입들(특히 브러시들)은 간단하거나 복잡한 형태로 분해될 수 있다.
이들 계층 중 어느 하나 또는 이들 클래스 중 어느 하나로 향하는 함수 호출은 직접 또는 간접적으로 처리될 수 있다는 점에 유의해야 한다. 예를 들어, 요구 처리기는 하나의 운영 체계에서 수신되는 요구를 다른 운영 체계에 의해 처리되는 API 호출로 변환하는 미들웨어 코드를 포함할 수 있다. 따라서, 본 명세서에서 사용되는 바와 같이, 함수는 실제 처리가 발생하거나 데이터 구조 및 클래스가 제공되는지에 관계없이 요구된 행동의 발생을 "유발(cause)"하는 프로그램에 의해 호출된다.
이해되는 바와 같이, 또한 도 2에 나타난 바와 같이, 애니메이션 시스템(220)은 전체 API에 고루 미친다. 설명되는 바와 같이, 애니메이션 값은 본질적으로 요소 속성 레벨(208), 비주얼 API(212)의 내부, 그리고 다른 자원들 중 어느 하나를 포함하는 어느 곳에나 전달될 수 있다. 타이밍 시스템은 또한 요소 및 비주얼 레벨들 양자에 노출된다.
일 실시예에서, 그래픽 계층 아키텍처(200)는 캐싱 데이터 구조(216)를 포함하거나 그렇지 않은 경우 이 구조(216)와 관련되는 하이 레벨 구성 및 애니메이션 엔진(214)을 포함한다. 캐싱 데이터 구조(216)는 후술되는 바와 같이 정의된 객체 모델에 따라 관리되는, 계층적으로 배열된 객체들을 포함하는 장면 그래프를 포함한다. 일반적으로, 비주얼 API 계층(212)은 프로그램 코드(및 레이아웃 시스템(210))에게, 객체를 생성하고, 객체에 데이터를 제공하기 위해 객체를 열고 닫는 등의 능력을 포함하는 캐싱 데이터 구조(216)에 대한 인터페이스를 제공한다. 즉, 하이 레벨 구성 및 애니메이션 엔진(214)은 통합 매체 API 계층(212)을 노출시키는데, 이 계층(212)에 의해 개발자들은 그래픽 정보를 표시하려는 그래픽 및 매체에 대한 의도를 표현하고, 기반 플랫폼에게, 이 플랫폼이 프로그램 코드에 대한 하드웨어의 사용을 최적화할 수 있도록 충분한 정보를 제공할 수 있다. 예를 들어, 기반 플랫폼은 캐싱, 자원 협상 및 매체 통합을 담당한다.
일 실시예에서, 하이 레벨 구성 및 애니메이션 엔진(214)은 명령어 스트림 및 아마도 다른 데이터(예를 들어 비트맵에 대한 포인터)를 고속의 로우 레벨 구성 및 애니메이션 엔진(218)으로 전송한다. 일반적으로, 로우 레벨 구성 및 애니메이션 엔진/렌더러(218)는 스크린으로의 실제 드로잉 및 합성을 관리하는 한 세트의 시스템을 제공한다. 본 명세서에서 사용되는 "하이 레벨" 및 "로우 레벨"이라는 용어는 다른 컴퓨팅 시나리오들에서 사용되는 것과 유사한데, 일반적으로 소프트웨어 컴포넌트는 보다 높은 컴포넌트보다 더 낮을수록 하드웨어에 더 가깝다는 점에 유의해야 한다. 따라서, 예를 들어, 하이 레벨 구성 및 애니메이션 엔진(214)으로부터 전송된 그래픽 정보는 로우 레벨 구성 및 애니메이션 엔진(218)에서 수신될 수 있는데, 여기서 이 정보는 하드웨어(222)를 포함하는 그래픽 서브 시스템에 그 래픽 데이터를 전송하는 데 사용된다. 본 발명은 2개의 계층 외에 다층 구성으로 확장될 수 있다는 점에 유의해야 한다.
또한, 해상도 및 장치 독립적인 사용자 인터페이스를 용이하게 하기 위하여 픽셀의 개념은 메인 API 내의 기본 단위로서 노출되지 않는다는 점에 유의해야 한다. 대신에, 하나의 단위가 일 인치의 1/96인 초기 좌표 시스템이 설정된다. 이것은 몇몇 시스템들(고해상도 모니터 또는 프린터)에서는 픽셀로 맵핑되지 않지만 dip 또는 px로 지칭될 수 있다. 길이에 있어서, dip 단위는 하나의 사용자 단위로 직접 변환된다. 다른 물리 단위들(in, cm, pt 등) 사이의 승수(multiplier)는 1 인치의 1/96로 고정된다. 이것은 스케일 변환이 이용되는 경우 물리적인 문제에서 승수가 지정되는 경우에도 승수가 드로잉되는 모든 것에 영향을 미친다는 것을 의미한다. 1 인치의 1/96의 값은 디폴트 사용자 단위가 디폴트 설정을 가진 최신 디스플레이 상의 픽셀과 동일하도록 선택되었다. 레이아웃 시스템 및 다른 사용자 코드가 이들이 렌더링하고 있는 장치의 출력 해상도를 위해 최적화될 수 있도록 이들에게 힌트를 제공하는 메커니즘이 제공될 수도 있다는 점에 유의해야 한다.
하이 레벨 구성 및 애니메이션 엔진(214)은 프로그램 코드(202)와 함께 프로그램 코드(202)에 의해 제공되는 그래픽 장면을 표현하는 장면 그래프를 구축한다. 예를 들어, 드로잉되는 각 항목은 시스템이 장면 그래프 데이터 구조(216) 내에 캐싱할 수 있는 드로잉 명령에 의해 로딩될 수 있다. 후술되는 바와 같이, 이러한 데이터 구조 및 드로잉되는 것을 지정하는 많은 다양한 방법이 있다. 또한, 하이 레벨 구성 및 애니메이션 엔진(214)은 선언형(또는 다른) 애니메이션 제어(예를 들 어 애니메이션 간격) 및 타이밍 제어를 제공하기 위하여 타이밍 및 애니메이션 시스템(220)과 통합된다. 애니메이션 시스템은 애니메이션 값이 본질적으로 예를 들어 요소 속성 레벨(208), 비주얼 API 계층(212), 및 다른 자원들 중 어느 하나를 포함하는 시스템 내의 어느 곳으로나 전송되는 것을 가능하게 한다. 타이밍 시스템은 요소 및 비주얼 레벨에 노출된다.
로우 레벨 구성 및 애니메이션 엔진(218)은 장면의 구성, 애니메이션 및 렌더링을 관리하며, 이 장면은 그래픽 서브 시스템(222)으로 제공된다. 로우 레벨 엔진(218)은 다수의 스레드(예를 들어 하나 이상의 애플리케이션으로부터)의 장면들에 대한 렌더링들을 합성하며, 렌더링 컴포넌트와 함께 스크린으로의 그래픽의 실제 렌더링을 구현한다. 그러나 종종 렌더링의 일부가 보다 높은 레벨에서 행해지는 것이 필요 및/또는 유익할 수 있다는 점에 유의해야 한다. 예를 들어, 보다 낮은 계층들은 다수의 스레드로부터의 요구를 서비스하지만, 보다 높은 계층들은 스레드 단위(per-thread basis)로 인스턴스화되며, 이에 따라 이미징 메커니즘(204)을 통해 보다 높은 레벨에서 시간 소모적 또는 스레드-특정 렌더링을 수행하고 비트맵에 대한 레퍼런스들을 보다 낮은 계층들로 전달하는 것이 가능하다.
MIL(200)은 펜, 브러시, 형상, 변환 및 효과를 포함하는, 전체 계층 스택을 통해 공유되는 한 세트의 자원들 및 클래스들과 같은, 개량된 그래픽 및 시청각 프로그래밍을 제공하도록 통합되는 다수의 개념을 제공한다. 또한, 점, 사각형 등을 포함하는 간단한 원시 함수 타입들이 제공된다. 펜 및 브러시는 이러한 다양한 레벨에서 어떻게 렌더링에 효과를 주는지를 설명하는 복잡한 타입들이다. 또한, 비 주얼 브러시로 지칭되는 특수 타입의 브러시가 제공되는데, 이 브러시는 프로그래머들이 임의의 그래픽 "메타파일"을 사용하여 (비주얼 브러시를 통해 명시적으로, 도는 비주얼 브러시를 참조하는 펜을 통해) 한 영역을 채울 수 있게 한다. 이것은 임의의 그래픽을 저장하여 사용하기 위한 압축 형태이므로, 그래픽 자원의 역할을 한다. 이러한 객체들을 직접 생성하는 데 사용되는 벡터 그래픽 마크업 신택스의 특정 프로파일이 있다. 드로잉 브러시는 전반적으로 비주얼 브러시와 유사하지만, 더 압축되고 요약된 것이며, 본질적으로 메타파일 브러시인 반면, 비주얼 브러시는 장면 그래프 브러시이다.
다른 클래스들은 채우기(fill), 스트로킹(stroking) 또는 클립핑을 위한 영역을 정의하는데 사용되는 복잡한 타입인 형상(Geometry)을 포함한다. 변환은 좌표 공간을 어떻게 변환하는지를 정의하기 위한 또 하나의 복잡한 타입의 계층 구조이다. 효과는 콘텐츠의 섹션에 임의의 필터 효과, 예를 들어 흐림(blur) 효과를 주기 위한 시스템을 설명한다. 이것은 또한 애드-인(add-in) 확장성 모델을 포함한다는 점에 유의해야 한다.
상기 타입들을 사용하여 스크린 또는 다른 타겟에 비트들을 제공하는 비주얼 API가 제공된다. 이것은 위에 소개된 스크린 분할 데이터 구조와 함께 시스템의 나머지(hWnd 또는 다른 메커니즘을 통해)에 대한 기본 레벨 후크업(base level hookup)을 포함한다. 이미징은 프로그래머가 이미지를 MIL 기반 시스템에 제공하고, 그로부터 취득할 수 있게 한다. 매체는 오디오 및 비디오를 포함하는 다른 형태의 매체를 사용하는 능력을 제공한다. 일반적으로, 비주얼 API는 요소 시스템 및 레이아웃 시스템 아래에서 동작하는 API 세트를 지칭하며, 보다 높은 레벨 대신에 직접적으로 비주얼과 함께, 그리고 비주얼로 프로그래밍하는 것을 지칭한다. 비주얼은 캐싱 데이터 구조(216) 내의 기본 객체이며, 스크린 상의 비주얼 사물들을 위한 유지 데이터 구조를 포함하며, 또한 성능을 위해 명령어 리스트 및 장치 특정 자원을 캐싱한다.
도 3 및 4는 각각 비주얼로 지칭되는 기본 객체를 포함하는 장면 그래프들(300, 400)의 예를 나타낸다. 일반적으로, 비주얼은 사용자에게 가상 표면을 표현하고 디스플레이 상에 가상 표현을 갖는 객체를 포함한다. 도 5에 도시된 바와 같이, 기본 클래스 비주얼은 다른 비주얼 타입들을 위한 기본 기능을 제공하는데, 즉 비주얼 클래스는 비주얼 타입들이 도출되는 추상 기본 클래스이다.
도 3에 나타난 바와 같이, 최상위 레벨(또는 루트) 비주얼(302)은 비주얼 관리자 객체(304)에 접속되는데, 이 객체는 또한 그래픽 데이터가 프로그램 코드에 대해 출력되는 윈도우(HWnd; 306) 또는 이와 유사한 유닛과 (예를 들어 핸들을 통해)관련된다. 비주얼 관리자(304)는 최상위 레벨 비주얼(및 이 비주얼의 임의의 자식들)의 윈도우(306)로의 드로잉을 관리한다. 도 6은 여기서 설명되는 그래픽 시스템의 객체 모델 내의 한 세트의 다른 객체들(620) 중 하나인 비주얼 관리자를 나타낸다.
드로잉하기 위해, 비주얼 관리자(304)는 전술한 미국 특허 출원들에 전반적으로 설명되어 있는 바와 같이 디스패쳐(308)에 의해 스케쥴된 대로 장면 그래프를 처리(예를 들어 트래버스 또는 전송)하여, 그에 대응하는 윈도우(306)에 대한 로우 레벨 컴포넌트(218; 도 2)로 그래픽 명령 및 기타 데이터를 제공한다. 장면 그래프 처리는 통상 로우 레벨 컴포넌트(218) 및/또는 그래픽 서브 시스템(222)의 리프레시 속도보다 느린 속도로 디스패쳐(308)에 의해 스케쥴된다. 도 3은 최상위 레벨(루트) 비주얼(302) 아래에 계층적으로 배열된 다수의 자식 비주얼(child Visual; 310-314)을 나타내는데, 이들 중 일부는 예를 들어 명령어 리스트 및 다른 비주얼들을 포함하는 연관된 명령 리스트들(318, 319)을 각각 구비한 드로잉 컨텍스트들(316, 317)(이들의 임시성을 나타내기 위해 점선 박스로 도시됨)을 통해 채워진 것으로 표현된다. 비주얼들은 또한 다른 속성 정보를 포함할 수 있다. 일반적으로, 기본 비주얼 클래스 상의 대부분의 액세스는 IVisual 인터페이스를 통해 발생하며, 비주얼은 도 5에 나타난 바와 같이 종속성 객체(Dependency Object)로부터 도출된다. 비주얼들은 또한 아래의 비주얼 클래스의 예에 도시된 바와 같이 다른 속성 정보를 포함할 수 있다.
비주얼은 그래픽 콘텐츠 및 한 세트의 자식들을 위한 컨테이너이다. 비주얼 상의 다양한 속성들은 비주얼의 렌더링 행동을 제어하는 데 사용될 수 있다. 예를 들어 비주얼 상에 클립을 설정함으로써 비주얼의 콘텐츠는 지정된 모양으로 클립된다. 다른 속성들은 변환, 혼합 모드, 불투명, 보기(show) 등이다. 이러한 모든 속성은 취득(get) 및 설정(set) 속성들을 통해 제어될 수 있다.
보기 속성은 비주얼을 보거나 숨기는 데 사용되는데, 예를 들어 거짓일 때 비주얼은 볼 수 없으며, 사실일 때 비주얼은 볼 수 있다. 더욱이, MIL 객체들(비주얼 API 계층의 비주얼 또는 요소 계층의 요소들이든지)는 계층 구조로 존재한다. 좌표 시스템은 이러한 계층 구조를 통해 상속된다. 이러한 방식으로, 부모는 렌더링 경로를 변경하고 이 부모의 자식들에게 적용되는 좌표 변환을 추구할 수 있다.
비주얼에 대한 변환은 그 비주얼에 대한 접속과 관련이 있다. 즉, 변환은 부모의 비주얼 컬렉션 자식 속성(VisualCollection Children property) 상의 [Get|Set]ChildTransform을 통해 설정된다. 후술되는 비주얼 컬렉션을 또한 참조 하자.
좌표 변환은 모든 것에, 이것이 비트맵 내에 있는 것처럼 균일한 방식으로 적용될 수 있다는 점에 유의해야 한다. 이것은 변환이 항상 비트맵에 적용된다는 것을 의미하는 게 아니라, 렌더링되는 것은 변환에 의해 동일하게 영향을 받는다는 것을 의미한다. 예를 들어, 사용자가 1 인치 폭의 둥근 펜으로 원을 드로잉한 후, 이 원에 대해 2의 X 방향 스케일을 적용하는 경우, 펜은 좌우에서는 2 인치 폭을, 상하에서는 단지 1 인치의 폭을 가질 것이다. 이것은 종종 합성(compositing) 또는 비트맵 변환(형상에만 효과를 미치는 골격 또는 형상 스케일과 반대)으로 지칭된다. 도 8은 스케일링 변환을 나타내는데, 변환되지 않은 이미지(800)는 좌측에, 불균일 스케일링된 변환된 이미지(802)는 우측에 도시되어 있다. 도 9는 스케일링 변환을 나타내며, 변환되지 않은 이미지(800)는 좌측에, 형상 스케일링된 변환된 이미지(904)는 우측에 도시되어 있다.
비주얼의 좌표 변환과 관련하여, TransformToDescendant는 기준 비주얼(reference Visual)에서 후손 비주얼(descendant Visual)로 가는 좌표 공간 변화를 반영한 변환을 리턴한다. 이어서, 변환은 예를 들어 기준 비주얼의 좌표 공간의 점을 후손 비주얼의 좌표 공간으로 변환하는 데 사용될 수 있다. TransformFromDescendant는 유사하게 후손 비주얼에서 기준 비주얼로 가는 좌표 공간 변화를 나타내는 변환을 리턴한다. 이어서, 변환은 후손 비주얼의 좌표 공간의 점을 기준 비주얼의 좌표 공간으로 변환하는 데 사용될 수 있다. 편의를 위해, 비주얼 API는 또한, 각각의 좌표 공간 변화에 대한 변환을 또한 리턴하는 TransformToAncestor, TransformFromAncestor, TransformFromVisual 및 TransformToVisual을 제공한다. 뒤의 두 API에서 비주얼들 사이의 관계는 지정되지 않는다는 점에 주목해야 한다. 이들은 공동 조상을 공유하는 한 심지어 비주얼 트리 내의 피어들(peers)일 수 있다. 본 실시예에서는 공동 조상을 발견한 후, 기준 비주얼에서 공동 조상으로의 좌표 변환을 계산한 다음, 공동 조상에서 타겟 비주얼로의 좌표 변환을 계산한다. 결과적인 변환은 예를 들어 지정된 비주얼들 사이의 점을 변환하는 데 사용될 수 있다.
비주얼의 콘텐츠의 경계 박스를 결정하는 데 사용될 수 있는 2개의 취득 속성, 즉 후손들의 모든 그래픽 콘텐츠의 경계 박스인 VisualDescendantBounds, 및 콘텐츠의 경계인 VisualContentBounds가 이용 가능하다. 이들에 대한 결합(Union)의 적용은 비주얼의 전체 경계들을 제공한다.
클립 속성은 비주얼의 클립핑 영역을 설정(및 취득)한다. 임의의 형상(형상 클래스는 도 10에 도시되고, 아래의 형상 섹션에 설명된다)이 클립핑 영역으로 사용될 수 있다. 일 실시예에서, 클립핑 영역에 대한 디폴트 설정값은 공백(null), 즉 클립핑이 없으며, 이것은 (-∞, -∞)에서 (+∞, +∞)까지의 무한히 큰 클립핑 사각형으로 간주될 수 있다.
불투명 속성은 비주얼의 콘텐츠가 불투명 값 및 선택된 혼합 모드에 기초하여 드로잉 표면 상에서 혼합되도록 비주얼의 불투명 값을 취득/설정한다. 혼합 모드 속성은 사용되는 혼합 모드를 설정(또는 취득)하는 데 사용될 수 있다. 예를 들어, 불투명(알파) 값은 0.0과 1.0 사이에 설정될 수 있으며, 선형 알파 혼합은 예를 들어 Color=alpha*foreground color+(1.0-alpha)*background color와 같은 모드로 설정된다. 예를 들어, 흐림, 단색(monochrome) 등의 특수 효과 속성과 같은 다른 서비스들은 비주얼 내에 포함될 수 있다.
비주얼은 또한 자식들의 세트를 관리하기 위한 자식 속성을 갖는다. 이것은 또한 비주얼이 적어도 임의의 자식들을 갖는지를 검사하는 HasChildren 속성을 제공한다. 자식 속성은 사용자가 자식들의 세트 상에 추가, 제거, 삽입 등과 같은 조작을 행하게 하는 비주얼 컬렉션을 리턴한다. 다음은 비주얼 컬렉션의 예를 나타낸다.
비주얼 컬렉션(VisualCollection) 내의 비주얼들의 순서는 비주얼들이 어떠한 순서로 렌더링되는지를 결정하는데, 즉 비주얼들은 가장 낮은 인덱스에서 가장 높은 인덱스로, 백에서 프론트로(페인팅 순서) 렌더링된다.
프록시 비주얼(ProxyVisual)은 장면 그래프 내에, 예를 들어 컨테이너 비주얼 아래에 2번 이상 추가될 수 있는 비주얼이다. 프록시 비주얼로 지칭되는 임의 의 비주얼은 루트로부터 다수의 경로에 의해 도달될 수 있으므로, 판독 서비스(TransformToDescendent, TransformFromDescendent 및 HitTest)는 프록시 비주얼을 통해 동작하지 않는다. 본질적으로, 임의의 비주얼에서 비주얼 트리의 루트까지는 하나의 기본 경로가 있으며, 이 경로는 어떠한 프록시 비주얼도 포함하지 않는다.
도 4는 컨테이너 비주얼과 드로잉 비주얼이 장면 그래프 내에서 관련되고 명령어 리스트 형태의(예를 들어 대응하는 드로잉 컨텍스트의) 관련 데이터를 갖는 예시적인 장면 그래프(400)를 나타낸다. 컨테이너 비주얼은 비주얼 기본 클래스로부터 도출되는 구조적 콘텐츠만을 갖는 비주얼이다. 비주얼들은 임의로 서로 중첩(nest)될 수 있다. 특히, 컨테이너 비주얼들을 중첩시키는 것은 정당하다. 컨테이너 비주얼의 주 목적은 IVisual 인터페이스를 통하지 않고 편리하게 액세스될 수 있는 비주얼들에 대한 컨테이너를 제공하는 것이다. 따라서, 컨테이너 비주얼은 모든 IVisual 메소드를 공용 메소드로서 다시 재구현한다. 컨테이너 비주얼의 자식들은 컨테이너 비주얼의 비주얼 컬렉션 자식 속성 상의 메소드로 조작될 수 있다.
도 5를 참조하면, 또 하나의 비주얼은 장면 그래프 내에 Win32 자식 HWnd을 배치하는 HwndVisual(505)이다. 구체적으로, 레거시 프로그램은 여전히, 이전의 그래픽 기술에 기초하여 자식 HWnd (기타)로 드로잉하는 WM_PAINT 메소드(등등)를 통해 동작한다. 새로운 그래픽 처리 모델에서 이러한 프로그램을 지원하기 위하여, HwndVisual은 Hwnd가 장면 그래프에 포함되고, 부모 비주얼이 재배치될 때 이동되는 것을 가능하게 한다. 2차원 세계와 3차원 세계 사이의 연결을 가능하게 하 는 3차원(3D) 비주얼과 같은 다른 타입의 비주얼(506)도 가능한데, 예를 들어 3차원 세계로의 뷰(view)를 갖는 2차원 비주얼을 통해 카메라와 같은 뷰가 가능하다. 이러한 3D 비주얼은 후술된다.
전술한 바와 같이, 비주얼들은 그들의 드로잉 컨텍스트를 형상, 이미지 소스 및 매체 데이터를 포함하는 다양한 드로잉 원시 함수로 채움으로써 드로잉될 수 있다. 더욱이, 이 전체 스택을 통해 공유되는 한 세트의 자원 및 클래스가 존재한다. 이것은 펜, 브러시, 형상, 변환 및 효과를 포함한다. 드로잉 컨텍스트 추상 클래스(DrawingContext abstract class)는 드로잉 비주얼, 유지 비주얼, 이미지 데이터 등을 채우는 데 사용될 수 있는 한 세트의 드로잉 및 컨텍스트 상태 동작들을 노출시킨다. 즉, 드로잉 컨텍스트 추상 클래스는 한 세트의 드로잉 동작들 및 푸시/팝(push/pop) 동작들을 노출시키는데, 각각의 드로잉 및 푸시 동작에 대해 상수를 독립변수(argument)로 취하는 메소드 및 애니메이터를 독립변수로 취하는 메소드의 두 메소드가 존재한다. 푸시/팝 동작들의 예는 PushTransform, PopTransform, PushClip, PopClip, PushOpacity, PopOpacity 등이다.
다양한 서비스(변환, 불투명 및 클립을 포함)는 드로잉 컨텍스트 상에 푸시 및 팝될 수 있으며, 푸시/팝 동작들은 각각의 푸시 호출에 대해 적절한 팝 호출이 존재하는 한 중첩될 수 있다.
PushTransform 메소드는 변환을 푸시한다. 후속 드로잉 동작들은 푸시된 변환에 관하여 실행된다. 팝 호출은 매칭 PushTransform 호출에 의해 푸시되는 변환을 팝한다:
마찬가지로, PushOpacity 메소드는 불투명 값을 푸시한다. 후속 드로잉 동작들은 지정된 불투명 값을 가진 임시 표면 상에 렌더링된 후 장면으로 합성된다. Pop()은 매칭 PushOpacity 호출에 의해 푸시되는 불투명을 팝한다:
PushClip 메소드는 클립핑 형상을 푸시한다. 후속 드로잉 동작들은 형상으로 클립된다. 클립핑은 포스트 변환 공간에 적용된다. Pop()은 매칭 PushClip 호출에 의해 푸시되는 클립핑 영역을 팝한다.
푸시 동작들은 팝 동작들이 푸시와 매칭되는 한 임의로 중첩될 수 있다. 예를 들어, 다음은 유효하다:
형상은 스트로크 또는 채우기 없이 벡터 그래픽 골격을 정의하는 한 타입의 클래스(도 10)이다. 각 형상 객체는 단순 모양(선 형상, 타원 형상, 사각 형상), 복합 단일 형상(경로 형상) 또는 조합 동작(예를 들어 결합, 교차 등)이 지정된 이러한 모양들의 리스트(형상 컬렉션)이다. 이러한 객체들은 도 10에 나타난 바와 같은 클래스 계층 구조를 형성한다.
도 11에 나타난 바와 같이, 경로 형상은 도형(Figure) 객체들의 컬렉션이다. 또한, 도형 객체들 각각은 도형의 모양을 실제로 정의하는 하나 이상의 세그먼트 객체로 구성된다. 도형은 세그먼트 컬렉션을 정의하는 형상의 서브 섹션이다. 이러한 세그먼트 컬렉션은 2차원 세그먼트 객체들의 단일 연결 시리즈이다. 도형은 한정된 면적을 가진 폐쇄된 모양이거나, 곡선을 정의하나 둘러싸인 면적을 정의하지 않는 연결된 세그먼트들의 시리즈일 수 있다.
도 12에 도시된 바와 같이, 형상(예를 들어 사각형)이 드로잉될 때, 후술되는 바와 같이 브러시 또는 펜이 지정될 수 있다. 더욱이, 펜 객체는 또한 브러시 객체를 가진다. 브러시 객체는 평면을 어떻게 그래픽으로 채우는지를 정의하며, 브러시 객체들의 클래스 계층 구조가 존재한다. 이것은 사각형 및 브러시 명령어들 및 파라미터들을 포함하는 비주얼이 처리될 때 결과되는 채워진 사각형(1202)에 의해 도 12에 표시되어 있다. 펜 객체는 후술하는 Thickness, LineJoin, LineCap, EndCap, MiterLimit, DashArray 및 DashOffset에 대한 속성들과 함께 브러시 상에 유지된다. 또한 후술하는 바와 같이, 몇몇 타입의 브러시(예를 들어 그래디언트 및 나인 그리드)는 그 자신을 사이징한다. 사용시, 이들 브러시의 크기는 예를 들어 브러시에 대한 GradientUnits/DestinationUnits가 RelativeToBoundingBox로 설정되고 드로잉되고 있는 원시함수의 경계 박스가 사용될 때 경계 박스로부터 얻어진다. 이러한 속성들이 Absolute로 설정되는 경우, 좌표 공간이 사용된다.
전술한 바와 같이, 또한 후술되는 바와 같이, 본 발명의 그래픽 객체 모델은 일반적으로 픽셀들로 평면을 커버하는 개념을 지향하는 브러시 객체 모델을 포함한다. 브러시 타입의 예는 도 13의 계층 구조에 나타나 있으며, 브러시 기본 클래스 아래에 그래디언트 브러시, 나인 그리드 브러시, 솔리드 칼라 브러시 및 타일 브러시를 포함한다. 그래디언트 브러시는 리니어 그래디언트 및 래디컬 그래디언트 객체를 포함한다. 드로잉 브러시 및 이미지 브러시는 타일 브러시로부터 도출된다. 대안적인 클래스들의 배열도 가능한데, 예를 들어 타일 브러시로부터 이미지 브러시, 비주얼 브러시, 비디오 브러시, 나인 그리드 브러시 및 드로잉 브러시가 도출될 수 있다. 브러시 객체들은 이들이 사용될 때 좌표 시스템과 어떻게 관련되는지, 그리고/또는 이들이 사용되는 모양의 경계 박스와 어떻게 관련되는지를 인식할 수 있다는 점에 유의한다. 일반적으로, 크기와 같은 정보는 브러시가 드로잉되는 객체로부터 추론될 수 있다. 구체적으로, 많은 브러시 타입은 이들의 파라미터들의 일부를 지정하기 위해 좌표 시스템을 사용한다. 이 좌표 시스템은 브러시가 적용되는 모양의 간단한 경계 박스에 대해 정의되거나, 브러시가 사용되는 때에 액티브한 좌표 공간에 대해 정의될 수 있다. 이들은 각각 RelativeToBoundingBox 모드 및 Absolute 모드로 알려져 있다.
비주얼 API
비주얼 API는 매체 통합 계층을 통한 드로잉에 대한 시작점이며, 비주얼 트리를 매체에 연결하는 비주얼 관리자 객체를 포함하는 많은 타입의 객체를 포함한다. 상이한 타입의 비주얼 관리자들(예를 들어 스크린, 프린터, 표면)은 그들의 특정 매체로의 비주얼 트리의 렌더링 프로세스를 관리한다. 비주얼 관리자는 "최상위 레벨 MIL 객체" 섹션에서 더 설명된다.
비주얼은 사용자가 드로잉을 행하는 곳이다. 비주얼은 비주얼 트리(후술하는 바와 같이 장면에 대한 구조인 컨테이너 객체) 내의 하나의 노드이며, 프로그램이 드로잉하는 장소를 제공한다. 상이한 용도에 각각 맞춰진 다양한 타입의 비주얼들이 있다. 비주얼은 Win32 hWnd의 비주얼/출력 측과 유사하다.
비주얼들은 부모 비주얼 액세스, 자식 비주얼 컬렉션, 임의의 형상에 기초한 클립핑, 불투명, 혼합 모드, 그 비주얼 및 그 자식들에 효과를 주는 변환, 히트 테스팅, 좌표 변환 서비스, 경계 박스 서비스 및 효과(래스터 및 벡터)를 포함하는 많은 능력을 제공한다.
비주얼 장면을 렌더링하기 위하여, 비주얼 트리는 트래버스되는데, 예를 들어 상하로, 좌우로 먼저 콘텐츠를 렌더링한 후, 좌우로 비주얼의 자식들을 트래버스한다. 비주얼의 자식들 중 어느 하나는 그 비주얼 자체의 콘텐츠 이전에 드로잉된다. 콘텐츠가 사용자에 대한 콜백(call back)을 요구하는 경우, 이것은 렌더링 시간 동안 동기적으로 발생한다. 시스템이 비주얼 트리를 장치로 (비주얼 렌더러를 통해) 렌더링하기 위해 행하는 것에 대한 소정의 의사 코드(pseudo-code)는 다음과 같다:
도출된 비주얼은 콘텐츠 렌더링 호출 동안에 사용자에 대해 콜백할 수 있다.
도 13은 일 실시예의 비주얼 클래스 계층 구조를 나타낸다. 렌더링 전달의 일부로서 발생하는 콜백(IRetainedVisual.Render에 대한 콜백 또는 PaintingVisual.RenderCore에 대한 콜백을 포함) 동안, 비주얼 트리는 성능의 이유로 "로킹(locking)"된다. 이러한 로킹은 전 컨텍스트에서 발생하는데, 이것은 비주얼이 어느 비주얼 트리에 속하는지에 관계없이 어느 컨텍스트도 로킹시에는 트리를 수정할 수 없다는 것을 의미한다. 트리가 로킹될 때, 비주얼의 자식들은 변경될 수 없으며, 다른 비주얼의 콘텐츠는 어떠한 방법(예를 들어 Open, set root 3D model 등)으로도 변경될 수 없고, 비주얼 상의 변환, 불투명, 클립, 혼합 모드 또는 효과가 설정될 수 없고, 히트 테스팅이 동작하지 않으며, 경계 정보 취득 동작이 이루어지지 않는다.
비주얼 상의 능력들은 IVisual 인터페이스를 통해 노출되어, 객체 모델을 보호하면서 능력들이 공개된다. 다음은 일 실시예의 IVisual 인터페이스이다.
비주얼은 콘텐츠 렌더링 및 자식들의 컬렉션을 포함한다. 변환, 클립, 불투명, 혼합 모드 등을 포함하는 다수의 속성이 비주얼 트리의 실제 렌더링을 제어하기 위해 사용될 수 있다. 비주얼이 콘텐츠 및 자식을 동시에 가질 필요가 없다는 점에 유의하자. 일 실시예에서, 콘텐츠 렌더링 및 자식 컬렉션은 메모리 사용을 최적화하기 위하여 주문에 의해 생성될 수 있다. 비주얼 API는 그의 사용자가 그것을 비주얼로부터 도출하여 특수화하는 것을 가능하게 한다.
자식들에 대한 변환은 타입 비주얼 컬렉션의 속성 자식들 상의 변환을 통해 수행된다.
변환 판독 서비스는 사용자가 하나의 좌표 프레임에서 다른 좌표 프레임으로의 집단 변환(aggregate transform)을 표현하는 매트릭스를 취득할 수 있게 하는 메소드를 제공한다:
TransformToAncestor 및 TransformToDescendant 메소드는 보다 효율적이지만, 호출자가 2개의 비주얼 사이의 관계를 알 것을 요구한다. 보다 일반적인 TransformTo/FomVisual 메소드는 공통 조상을 발견하고 그 비주얼에 대한 변환을 계산한다. 이들은 캐시가 갱신되도록 하고 OnRender가 임의의 비주얼 상에 호출되게 할 수 있다는 점에 유의하자. 비주얼들이 연결되지 않거나 축퇴 변환(degenerate transform)이 발생하는 경우에는 예외가 생긴다.
경계 변환이 또한 제공된다:
VisualDescendantBounds는 현재 비주얼의 후손들에 대한 콘텐츠 경계 박스들의 결합을 리턴하지만, 이는 현재 비주얼의 콘텐츠를 포함하지 않는다. VisualContentBounds는 현재 비주얼의 콘텐츠에 대한 경계 박스를 리턴한다.
불투명 속성(예를 들어 2배)은 비주얼이 그의 부모로 합성될 때 비주얼에 적용할 선택적 불투명 값을 지정한다. 디폴트로, 이 값은 1.0이며, 콘텐츠가 완전히 불투명하게 보이게 한다. 이 값은 서브 그래프 내의 임의의 다른 불투명 데이터로 승산되므로 1.0의 불투명도는 아무 것도 변경하지 않는다. 0.0의 불투명도는 전체 콘텐츠를 투명하게 하며, 0.25의 값은 불투명도가 그 명목값(nominal value)의 25 퍼센트가 되게 하는 등등으로 된다. 불투명도는 혼합 모드 이전에 적용된다.
혼합 모드는 이 비주얼이 합성(composition)될 때 서브 그래프의 콘텐츠 및 목적지에 적용할 선택적 혼합 모드를 지정하는 속성이다. 디폴트로, 이 값은 BlendMode.Normal이며, 목적지로의 알파 채널 인식 합성을 수행한다. 이러한 속성을 소정의 다른 값으로 설정하는 것은 소스로서의 비주얼의 콘텐츠 및 목적지로서의 렌더링 타겟의 콘텐츠와의 합성을 수행할 것이다. 이것은 불투명 속성이 적용 된 후에 적용된다.
기본 비주얼 클래스는 비주얼들이 공통으로 갖는 특징들에 대한 인터페이스를 제공한다:
ContainerVisual은 비주얼 클래스로부터 직접 도출되며, 보호되는 속성들을 공개 속성으로 승진(promote)시킨다. 이것은 사용자가 새로운 클래스를 도출할 필요 없이 비주얼 컨테이너를 생성할 수 있게 한다.
RetainedVisual은 드로잉에 사용될 수 있는 "유지 명령어 스트림(retained instruction stream)"을 소개하는 비주얼이다:
명령어 스트림은 OnDemand 모드에서 사용될 수 있는데, 이 모드에서 사용자는 필요에 따라 렌더링하기 위해 콜백된다. 사용자는 IRetainedRender를 구현하도록 요구된다. 명령어 스트림은 Imperative 모드에서 사용될 수 있는데, 이 모드에서 사용자는 직접 RenderOpen을 호출하여 드로잉 컨텍스트를 취득할 수 있다. 일반적으로, 사용자는 한번에 이들 모드 중 하나를 사용하지만, 이들 모드는 혼합 방식으로 사용될 수도 있다.
RenderOpen 및 RenderAppend는 현재의 스트림에 효과를 주며, 다양한 시나리오에서 이용 가능하다. 이들은 이 비주얼이 현재 Render 콜백 내에 있는 경우에 개시된다. RenderOpen은 RetainedVisual 내에 있는 모든 이전 콘텐츠를 소거하는 반면, RenderAppend는 새로운 콘텐츠를 스트림의 끝에 첨부한다. 사용자가 비주얼 상에 IRetainedRender를 구현한 경우, 사용자는 OnDemand 모드가 또한 사용되어야 한다는 것을 시스템에게 알린다. 시스템은 RenderBounds 속성 내에 설정된 값을 Render 호출에 의해 제공될 콘텐츠에 대한 경계로서 사용한다. 시스템은 IRetainedRender가 구현될 때 장면을 최적화하고 임의의 시간에 콘텐츠를 폐기하도록 결정할 수 있다. RenderBounds는 Rect.Infinite 또는 미설정 값이 가능한 대안이지만 빈 사각형을 디폴트로 가질 것이다. 가상화 성능 이득(virtualization performance gain)이 콜백에 수반되도록 하기 위하여, 사용자는 적절한 값을 설정해야 한다.
장면을 렌더링할 때, 시스템은 각 비주얼을 개념적으로 검사한다(실제로 시스템은 대부분의 시간에 대부분의 비주얼들을 무시할 수 있다는 점에 유의한다). 비주얼이 IsVisualInvaild를 참으로 설정하고, RenderBounds에 기초하여 비주얼의 콘텐츠가 요구될 경우, 시스템은 비주얼의 콘텐츠를 채우기 위하여 IRetainedVisual.Render를 호출할 것이다. 이것은 이미 들어있는 임의의 콘텐츠를 대체한다. 사용자는 Invalidate를 호출함으로써 시스템에게 콘텐츠 스트림을 폐기하도록 수동으로 지시할 수 있다.
IRetainedRender가 구현되지 않은 경우, IsVisualInvalid는 항상 거짓을 리턴할 것이다. Invalidate는 아무것도 하지 않을 것이다. IRetainedRender는 모든 렌더링 콜백 케이스에 사용될 만큼 일반적이지 않기 때문에 (예를 들어 IRender 대신) 그렇게 명명된 것이다. 예를 들어, PaintingVisual은 무효 사각형과 함께 콜백한다.
DrawingVisual은 RetainedVisual과 매우 유사하지만, 유도(derivation) 없이 사용될 수 있도록 설계된다. 보호된 메소드는 공개 메소드로 승진된다. 더욱이, Render 콜백 또는 IRetainedRender 인터페이스를 구현할 필요가 없다. 이 때문에, 콘텐츠는 IRetainedRender가 RetainedVisual 상에 구현되지 않을 때와 유사하게 항상 유지된다.
PaintingVisual이 또한 제공된다:
RetainedVisual이 유지 명령어 스트림을 추가하는 반면, PaintingVisual은 본질적으로 표면에 의해 지지(back)된다. 시스템은 표면을 가상화할 수 있으며, 성능 요건이 만족되는 한 렌더링 명령어들을 유지할 수 있다. 이 때문에, 표면은 사용자에 의해 액세스될 수 없다.
RetainedVisual에 대한 PaintingVisual의 한가지 차이는 애니메이션을 허용하지 않는 StaticDrawingContext를 메소드들이 제공한다는 점이다. 애니메이션화된 독립변수가 어딘가에 사용되는 경우, 예외가 생긴다. 또 하나의 차이는 "Append"가 메모리 비용면에서 훨씬 더 싸게 명령어 스트림을 증가시킨다는 것이다. 또한, 본질적으로 사용자에 대해 하드 클립을 설정하는 PaintingBounds가 요구되며 필요하다. 이것은 클립 속성과 다른데, 이것은 비주얼의 콘텐츠의 경계를 이루는 반면, Clip은 비주얼의 콘텐츠 및 그 자식들 모드를 클립하기 때문이라는 점에 유의한다. RenderCore(IRetainedVisual.Render와 유사)가 또한 구현되는데, 해상도가 변하거나, 시스템이 소정의 이유로 콘텐츠를 다시 렌더링하는 것이 필요한 경우, 사용자는 이 메커니즘을 제공한다.
PaintingVisual은 잠재적으로 SurfaceVisual보다 훨씬 더 가벼운데, 이는 표면에 의한 이 비주얼의 명시적인 지지가 없기 때문이다. 대신에, 이것은 표면에 의해 지지되는 소정의 보다 낮은 지점에 있는 표시 트리 내의 한 노드이다.
SurfaceVisual을 달성하기 위하여, 사용자는 RetainedVisual을 생성하고, DrawImage를 호출한 다음, 장면들 뒤의 이미지를 변경해야 한다. 이 경우, 사용자는 시스템이 콜백하도록 시키는 대신 래스터화(rasterization)를 명시적으로 제어하고 있다. 이미지 상에 직접 작용하는 즉석 모드 API가 존재할 것이다. 이 API는 사용자가 그 이미지 상에 작용하는 StaticDrawingContext를 취득할 수 있게 한 다. SurfaceVisual에 대한 API는 hWnd, DUser 장치(Gadget) 또는 트라이던트 표시 트리 노드(Trident display tree node)와 유사하다는 점에 유의하자. "Appending" 콘텐츠는 (실제로 이미 존재하는 것에 대해 합성하는 스몰 델타를 만듦) 저렴한 동작이다. 대체로, RetainedVisual과 달리 콘텐츠를 첨부하는 것에 메모리 페널티는 없으며, 이에 따라 RenderAppend는 명령어 스트림을 점점 더 길게 만들어, 잠재적으로 기하 급수적으로 증가시킨다. 이 비주얼을 지지할 수 있는 표면이 오고 갈 수 있기 때문에, 비주얼은 "온디맨드(on-demand)" RenderCore 버추얼을 구현하도록 요구된다.
PaintingVisual에 대한 주요 이용 시나리오는 WM_PAINT 페인팅 모델 주위에 크게 구축되는 애플리케이션 코드의 포팅(porting)이다. 이것은 또한 거의 변경되지 않고 밀도가 높은 정적 콘텐츠(static content)에 유용하다. PaintingVisual은 메타파일 또는 진정한 표면(true surface)에 의해 지지될 수 있다는 점에 유의한다. 시스템은 실행 시간에 예를 들어 메모리 및 성능 관계에 기초하여 어느 것이 보다 적절한지를 결정할 수 있다. 그러나 소정의 지점을 지나면 새로운 콘텐츠를 첨부하는 것이 보다 많은 메모리를 소모하지 않는 것이 보장된다. 시스템은 필요에 따라 메타파일과 표면 스토리지 사이에서 전환할 수 있다.
최상위 레벨 MIL 객체
쉽게 이해할 수 있듯이, 일반적인 윈도우 시나리오에서 동작하는 다양한 객체들이 제공된다. 이들은 정식 클래스일 필요는 없다는 점에 유의한다(예를 들어, 명시적인 스케쥴러 인터페이스 또는 객체가 존재하지 않는다).
이러한 하나의 객체는 드로잉될 메인 콘텐츠를 포함하는 객체인 비주얼 트리를 포함한다. 제어는 트리의 비주얼들로부터 직접 도출된다. 비주얼들은 장치 및 컨텍스트에 독립적이다.
렌더링 타겟은 비주얼이 드로잉되는 장치이다. 이 객체(예를 들어 스크린)는 그 자신의 오염 또는 무효화 메커니즘을 가질 수 있는데, 이는 레거시 hWnd에 의해 비주얼 시스템을 지지하는 데 필요하다. 다양한 렌더링 타겟들은 윈도우 내의 스크린, 프린터, 메타파일, 표면, 및 장면의 나머지 부분으로부터 분리되어 드로잉되는 장면의 일부인 "서브 윈도우"를 포함한다. 이것은 크로스 스레드 드로잉을 가능하게 하는 메커니즘이며, 로우 레벨 엔진의 합성 가능 객체들과 동등하다.
다른 드로잉 관련 객체들은 비주얼 트리를 렌더링 타겟 상에 드로잉하도록 구성된 객체를 포함하는 비주얼 렌더러, 및 비주얼 트리를 렌더링 타겟 상에 언제 드로잉할지를 아는 디스플레이 스케쥴러 객체를 포함한다. 시간 관리자는 타이밍 노드들의 세트에 대한 컨텍스트 객체이며, 스케쥴러가 틱 온(tick on)을 호출하는 객체이다.
다음은 스크린에의 드로잉에 대한 제어 흐름의 예이다.
1. 사용자는 소정의 방식으로 UiContext를 취득하고, 비주얼 트리의 변경을 개시한다. 이것은 애플리케이션의 시동 동안이거나, 아마도 UI 입력 이벤트에 대한 응답일 수 있다.
2. 오염 통지가 비주얼 트리로 전파된다. 루트 비주얼은 어느 비주얼 렌더 러와 연관되어 있는지를 알고, 오염 통지를 전송한다. 이 통지는 사적이다(privite).
3. 비주얼 렌더러는 공개 이벤트를 통해, 자신이 변경되었으며 그의 렌더링 타겟과 동기적이지 않다는 것을 보고한다.
4. 스케쥴러는 언제 어디서 이 상황을 실제로 조정하여 드로잉이 발생하게 할 것인지를 결정한다. 일반적으로, 이것은 작업 항목을 디스패쳐로 전송함으로써 이루어진다. 그러나 사용자는 다른 것을 행할 수도 있다.
5. 사용자는 UiContext를 산출하고, 디스패쳐가 실행되게 한다.
6. 디스패쳐는 실행되어 스케쥴러에게 연기된 작업 항목을 호출해준다. (대부분, 단일 컨텍스트 내의 임의의 연기된 작업 항목들은 연합된다. 또한, 이것은 스레싱(thrashing)을 줄이는 레이아웃 시스템과 함께 록스텝(lockstep)을 실행할 수 있다.
7. 스케쥴러는 그의 주요 갱신 루프를 실행한다:
a. 시간 관리자를 체크한다.
b. 다른 것들 중에서 레이아웃을 실행한다.
c. 비주얼 렌더러에게 새로운 변경을 렌더링 타겟으로 렌더링하도록 지시한다. 그러면, 렌더러는
i. 비주얼 트리의 오염 부분을 워킹(walking)하여 내부의 캐시된 경계 박스를 갱신한다.
ii. 모든 필요한 "온-디맨드" 비주얼을 렌더링하기 위해 호출한 다. (디폴트로, "온-디맨드" 비주얼들은 그들의 경계로서 빈 사각형을 가지며, 따라서 이들은 레이아웃이 실행되어 그들을 셋업할 때까지 호출되지 않는다.)
iii. 오염 부분을 다시 워킹하여, 필요한 렌더링 갱신을 보다 낮은 레벨의 그래픽 시스템으로 전송한다.
비주얼 시스템은 디스패쳐에 대해 아무 것도 모른다는 점에 유의한다. 그러한 세부 사항을 관리하는 일은 스케쥴러 객체에 맡겨진 것이다. 스케쥴러는 임의의 적절한 작업 흐름을 행할 수 있다.
더욱이, 증가 비주얼 렌더러 및 스냅샷 비주얼 렌더러의 아이디어가 존재한다. 비주얼이 한번에 하나, 단 하나의 증가 비주얼 렌더러에 속하는 것이 바람직할 수 있다. 이러한 제한은 비주얼 자체 상에서의 효율적인 데이터의 캐싱을 위해 필요하다. 그러나 전체 비주얼 트리를 렌더링 타겟으로 스냅샷하기 위한 방법을 또한 갖는 것이 합리적이다. 이 경우, 비주얼 트리와 렌더러 사이에는 계속적인 연결이 존재하지 않는다. 이것은 고해상도 스크린 그랩(grab)을 취득하기 위해 또는 비주얼 트리(스크린 상에 있을 때)를 직접 프린터로 전송하기 위한 이용일 수 있다.
윈도우는 상기의 렌더링 타겟의 역할을 한다. 이것은 또한 hWnd에 대한 관리된 교체물이다.
윈도우 관리자 제어는 이 객체의 외부에 있지만, 속성들(예를 들어 Size)에 판독/기록 값들을 만들어주고, 위치, 윈도우 제목(window title) 등과 같은 추가 속성을 제공함으로써 WindowContext와 통합될 수 있다. Size는 윈도우의 크기를 물리적 단위(1 인치의 1/96)로 나타낸다는 점에 유의한다. 이것은 픽셀 크기가 아니다. 윈도우로 렌더링되는 데이터가 비디오 모드 스위치 또는 로컬 콘솔에서 원격 단말 서버 세션으로의 스위치 등과 같은 소정의 이유로 누실되는 상황이 있을 수 있다는 점에 유의한다.
VisualRenderers 및 VisualManagers는 다른 객체들이며, 비주얼 트리를 렌더링 타겟으로 렌더링하는 것을 담당한다. VisualRenderer는 매체로 렌더링하는 간단한 "원 샷" 모델을 제공하는 반면, VisualManager는 비주얼들의 트리와 비주얼들이 렌더링되고 있는 타겟 사이의 유지된 연결을 설정한다. 이것은 매체로의 "증가(incremental)" 렌더링을 지원한다.
다음은 일 실시예에서 기본 VisualRenderer가 무엇으로 보이는가의 일례이다:
클래스는 "디폴트" 매체가 존재하지 않으므로 공개적으로 인스턴스화될 수 없다. VisualRenderer는 또한 ContextAffinity 객체이다.
BackgroundColor 속성이 제공된다:
이 속성은 비주얼 관리자의 디폴트 백그라운드 칼라이며, 비주얼 관리자는 이 속성을 VisualManagers에 대해 투명하게 디폴트화할 수 있다. 그러나, 소정의 매체들(예를 들어 레거시 HWnds로의 렌더링)은 픽셀 단위의 투명성을 지원할 수 없으며, 따라서 각 VisualManager는 이 속성에 대한 자신의 디폴트를 정의할 수 있다. 대부분의 애플리케이션은 이 속성을 무시하며, 예를 들어 시스템 윈도우 백그라운드 칼라로 또는 투명하게 설정될 수 있다.
RootVisual 속성은 렌더링을 위한 루트 비주얼을 식별한다:
이것은 공백을 디폴트로 갖는다. RootVisual 속성이 공백일 때, VisualManager는 백그라운드 칼라를 매체 상에 드로잉한다.
RootSize 속성은 가상 단위로 렌더링 타겟의 크기를 리턴한다. 예를 들어, 윈도우에 의해 지지되는 VisualManager에 대해, 이것은 윈도우의 클라이언트 크기가 될 것이다:
해상도 정보가 또한 제공된다:
모든 매체는 픽셀들에 의해 지지되지 않더라도 장치 해상도를 갖도록 요구된다. 예를 들어, 인쇄시, 메타파일로의 캡처링의 경우에도, VisualManager를 통해 이용 가능한 해상도 정보가 만들어져 콘텐츠가 이 해상도를 위해 최적화될 수 있도록 할 필요가 있다. 메타파일 캡쳐의 경우에, 비교적 높은 디폴트 해상도를 사용하면서 사용자가 그 해상도를 직접 구성하도록 할 수 있다는 점에 유의한다.
RootVisual에 대해 셋업된 초기의 "world to device" 변환은 비주얼에서의 하나의 단위가 장치 상에서 일 인치의 1/96과 동일하도록 만든다. 예를 들어, 192 dpi인 장치에 의해 지지되는 ScreenVisualManager가 존재하는 경우, 초기 변환은 RootVisual에 대한 좌표 프레임 내의 한 단위가 장치 상에서의 2개의 단위와 동일 하도록 셋업되어야 한다. 이 경우, ResolutionInformation.PixelSize는 각 픽셀이 일측에서 1 인치의 1/48임을 지시하는 (0.5, 0.5)를 리턴한다.
VisualManager는 루트 비주얼 및 렌더링 타겟에 대한 장기 접속을 설정하며, 차이들을 추적한다:
WindowVisualManager는 스크린 상에 드로잉하기 위한 주요 방법이다. 이것은 VisualTree의 WindowContext로의 렌더링을 관리한다.
드로잉
컨텍스트
DrawingContext API는 비주얼을 채우거나 ImageData로 렌더링되는 비주얼 콘텐츠를 구축하는 방법에 대한, 당업자에게 친숙한 "컨텍스트 기반" 프로그래밍 모델을 제공한다. 이 섹션은 DrawingContext 클래스는 물론, DrawingContext를 취득하고 RetainedVisual/DrawingVisual 내에 비주얼 콘텐츠를 열거하는데 필요한 클래스 및 진입점을 설명한다.
애플리케이션은 DrawingContext를 직접 구축하지 않으며, 노출되는 DrawingContext 버전은 추상 클래스이다. 비주얼 콘텐츠를 넣을 DrawingContext를 취득하기 위한 많은 방법이 있다. 이들은 명령을 발행할 DrawingContext를 각각 리턴하는 RetainedVisual.RenderOpen() 또는 RetainedVisual.RenderAppend()를 포함한다. 다른 방법은 IRetainedRender.Render(), DrawingVisual.RenderOpen(), DrawingVisual.RenderAppend(), 및 PaintingVisual.PaintingOpen() 또는 PaintingVisual.PaintingAppend()(다만, PaintingVisuals은 애니메이션을 처리하지 않음)를 포함한다. ImageData(또는 ImageData의 서브 클래스)는 고정 해상도 비트맵 표면 상에 렌더링하기 위한 DrawingContext를 리턴하는 메커니즘을 갖는다. ImageData도 애니메이션을 처리하지 않는다.
다음은 DrawingContext API를 설명한다:
DrawingContext 객체의 메소드들의 대부분은 당업자에게 자명하지만, DrawingContext는 ContextAffinityObject이며, 단일 UIContext로부터만 사용되어야 한다는 점에 유의해야 한다. DrawingContext 객체는 또한 IDisposable이며, C#에서 추천 패턴은 예를 들어 RenderOpen/Append로부터 수신된 경우 "using" 절(clause)에서 이들을 사용해야 한다. 또한, DrawArc, DrawPie, DrawBezier 및 DrawPolyline과 같은 메소드들은 여기에 없다는 점에 유의하자. 이들은 관련 형상의 구축 및 DrawGeometry의 사용을 요구한다(후술됨).
또한, 다수의 Push* 메소드가 존재하는 반면, 단일 Pop 메소드만이 존재한다. 이것은 중첩된 특성(attribute)이 존재할 수 없다는 것을 의미한다. Push*()에 의해 설정된 특성들은 적절히 구성된다. 예를 들어, Clip은 Intersection 연산자를 통해 구성되고, Opacity는 Multiplication 연산을 통해 구성되며, Transform 은 ComposeTransform 연산을 통해 구성된다.
사용자는 예를 들어 공백 브러시 또는 공백 펜으로 DrawGeometry를 호출할 수 있기 때문에, 브러시 및 펜 양자에 대한 공백들로 그것을 호출하는 것이 유효하지만, 렌더링되거나 히트 테스트할 것이 아무것도 존재하지 않을 것이다.
애니메이션되지 않는 타겟에서 사용될 때(예를 들어, 래스터로 직접 렌더링할 때) 드로잉 컨텍스트로 제공되는 임의의 애니메이션 속성들은 타임 제로로 스냅된다(애니메이션되지 않는 타겟은 "현재(now)" 시간으로 스냅될 수 있다). 이것은 동적 DrawingContext에 대해 기록된 코드가 애니메이션을 처리하지 않는 DrawingContext를 사용하는 것으로 보다 쉽게 전이(transition)하는 것을 가능하게 한다.
유지 비주얼의 내부의 콘텐츠의 열거는 콘텐츠를 삽입한 DrawingContext와 밀접하게 관련되어 있다. 비주얼의 콘텐츠의 열거 및/또는 명령어 스트림의 변경은 후술하는 바와 같이 필요에 따라 변경가능(Changeable) 메커니즘을 통해 수행될 수 있다. 일반적인 아이디어는 "푸시 모델" 열거 메커니즘을 제공하는 것이다.
DrawingContext 클래스 자체는 DrawingContextWalker라고 하는 DrawingContext의 서브 클래스인, 콘텐츠의 푸시 모드 워킹을 등록하기 위한 인터페이스를 제공한다 (메소드들의 대부분은 추상으로 유지된다). 사용자는 DrawingContextWalker를 서브 클래스화한 후, 인스턴스를 비주얼로 전달하여 열거를 개시한다. 비주얼은 적절한 DrawingContext 메소드를 콜백하여 갖고 있는 콘텐츠를 통신한다. DrawingContextWalker는 또한 열거가 어떻게 진행되고 있는지(즉, 예를 들어 즉시 열거를 중지해야 하는지)를 제어하기 위하여 조작될 수 있는 상태를 제공한다.
다음은 DrawingContextWalker 객체에 대한 코드 예이다:
WalkContent 메소드는 DrawingContextWalker 기본 클래스 내에 제공된다:
사용자는 이것을 서브 클래스화하고, 필요에 따라 모든 추상 메소드를 구현한다. 이어서, 사용자는 개체의 인스턴스를 생성하고, 그 위에서 WalkContent를 호출한다. 이어서, WalkContent는 비주얼을 워킹할 때 적절한 메소드를 콜백한다. 이들 메소드 중 어느 하나의 구현은 필요에 따라 보호 메소드 StopWalking()을 호출함으로써 워킹을 중지할 수 있다. 비주얼 상의 DrawingContext가 렌더링을 위해 열릴 때 워킹을 시작하는 것은 불법이라는 점에 유의한다.
옵션은 워킹이 어떻게 진행되는지를 결정한다:
IncludeAnimations가 설정되면, 워커는 애니메이션 콘텐츠와 함께 적당한 메소드를 호출한다. 그렇지 않은 경우, 콘텐츠의 순간 값이 DrawingContextWalker 메소드로 제공된다.
DrawingContext는 DrawingContextWalker 클래스를 통해 리턴되는 순서 및 구조로 비주얼에 콘텐츠의 순서 및 구조를 제공할 수 있는 PreserveReadbackOrder 부울을 가진다. 이것은 거짓을 디폴트로 하지만, 순서를 유지하는 것이 중요할 때 콘텐츠가 삽입되기 전에 참으로 설정될 수 있다. 예를 들어, 전술한 바와 같이, DrawGeometry는 공백 브러시 및 공백 펜을 구비할 수 있다. PreserveReadbackOrder이 참인 경우, 이 명령이 비주얼의 상태 내에 유지되는 것이 필요하다. PreserveReadbackOrder이 거짓인 경우, 그 구현은 이 명령을 자유롭게 폐기할 수 있다다.
이러한 푸시 방법은 다른 타입 안전 방법들보다 많은 이점이 있다는 점에 유의해야 하는데, 그 이점들은 병렬 세트의 타입들이 목록의 출력을 반영(reflect)할 필요가 없으며, 콜백 인터페이스 내의 힙(heap) 할당에 대한 요구가 반드시 존재하지는 않는다는 것을 포함한다. 또한, 메소드들은 역전송(pass back)할 객체를 생 성하지 않고 직접 호출될 수 있으며, DrawingContext 인터페이스는 이미 존재하고, 워킹을 가능하게 하기 위해 비주얼 자체 상에 필요한 추가적인 API가 존재하지 않는다.
비주얼 콘텐츠의 변경은 또 하나의 고려 사항이다. VisualContent에 대한 변경을 표현하는 하나의 방법은 여기에 설명되는 바와 같이 StatusOfNextUse==UseStatus.ChangeableReference와 함께, Changeable의 서브 클래스인 자원들(펜, 브러시 등)을 사용하는 것이다. 이것은 DrawingContext로 전송되는 관리된 구조 내에 있는 데이터에 대한 참조가 애플리케이션에 의해 유지되는 것을 가능하게 한다. 이것은 변경이 만들어질 수 있는 균일한 방법을 나타내며, 이 객체들은 이들이 명시적으로 설정된 공지의 상태에 있기 때문에, 그 구현은 어떤 객체들이 변경될 가능성이 있는지를 알게 된다. 이것은, 예를 들어, (추가를 위한 RenderAppend()가 존재하더라도) 명령들의 순서의 변경, 또는 명령들의 추가 또는 삭제를 허용하지 않는다는 점에 유의할 것이다.
드로잉
드로잉 클래스는 드로잉 명령들의 컬렉션을 포함한다. 이것은 DrawingVisual 상에 저장된 콘텐츠와 정확히 같으며, DrawingContext에 의해 구축된다. 드로잉은 변경이 불가능할 때 컨텍스트 친화성(affinity)을 갖지 않으며, 따라서 드로잉 및 관련 클래스 DrawingBrush는 드로잉 자체가 변경 불가능할 때 컨텍스트들에서, 그리고 디폴트 속성 시트들에서 사용될 수 있다.
드로잉은 자식들을 반복하거나 부모를 발견하는 수단을 제공하지 않는다는 점에서 계층 구조를 지원하지 않지만, DrawingContext를 통해 하나의 Drawing이 다른 Drawing 내에 드로잉될 수 있다. Drawing은 DrawDrawing(Drawing)을 통해 DrawingContext 내에 드로잉될 수 있으며, DrawingBrush에 대한 콘텐츠 설명서로서 사용될 수 있다.
드로잉은 완전히 애니메이션이 가능하며, RetainedVisual과 동일한 방식으로 재판독(readback)/반복(iteration)을 지원한다.
변경가능 패턴
설명의 목적으로, 본 발명은 주로 그래픽 장면 내의 예시 객체들이 구성되고, 사용되고, 변경되는 프로그래밍 환경과 관련하여 설명된다. 그러나, 본 발명은 그래픽 관련 프로그래밍 환경에서 상당한 이익을 제공하지만, 본 발명은 그래픽 관련 프로그래밍 환경에 국한되는 것이 아니라, 많은 다른 타입의 프로그래밍 환경에 보다 일반적으로 적용된다는 점을 이해할 것이다.
일 실시예에서, 본 발명은 공통 기본 클래스, 예를 들어 System.Windows.Changeable로부터 도출되는 타입들의 단일 세트를 제공한다. 임의의 클래스는 Changeable 클래스로부터 도출되어 Changeable이 제공하는 값-타입 시맨틱(value-type semantics)을 얻음으로써 변경가능(mutable)하게 될 수 있다. 예를 들어, 그래픽 프로그래밍에서, 객체 모델은 전술한 미국 특허 출원 번호 10/402,268에 일반적으로 설명되어 있는 바와 같이 브러시, 펜, 형상, FloatAnimation, GradientStop, 세그먼트 등을 포함한다. 예를 들어, 드로잉 브러시에 대한 계층 구조는 다음과 같은 것일 수 있다:
Object: Changeable:Animatable:Brush:TileBrush:DrawingBrush
기본적인 이용을 목적으로, 변경가능 객체는 다음의 속성 및 메소드를 포함한다:
IsChangeable 속성은 변경가능 객체가 그의 현재의 값에 따라 수정될 수 있는지의 여부를 지정한다. 예를 들어, 브러시의 불투명 속성을 설정하려는 시도는 그 브러시 객체가 참과 동일한 IsChangeable 속성을 갖는 경우에만 성공하게 된다. 그렇지 않은 경우에는, 예외가 발생한다. 변경가능 객체는 구성시 참과 동일한 IsChangeable 속성을 디폴트로 가지며, 따라서 즉시 수정될 수 있다.
도 14에 나타난 바와 같이, 예를 들어 애플리케이션 프로그램으로부터 시작되는 함수 호출을 통해, 변경가능 클래스(1404)로 지향되는 요구(1402)가 수신된다. 일반적으로, 상태 머신(1408)을 포함하는 요구 핸들러(1406)가 요구를 처리하고, 지원 데이터 구조(1410)를 통해 상태 및 객체 데이터를 유지하며, 후술하는 바와 같이 현재의 속성 상태에 기초하여 데이터 구조를 적당한 속성 상태를 가진 복사본(1412)으로 복제한다. 예를 들어 요구가 현재의 속성 상태 내로부터 허용되지 않는 전이를 요구할 때, 예외(1414)가 발생할 수 있다. 속성 상태는 도 15-17을 참조하여 후술된다.
변경가능 클래스로 향하는 함수 호출은 직접 또는 간접적으로 처리될 수 있다는 점에 유의한다. 예를 들어, 도 14의 요구 핸들러(1406)는 상태 머신에 인터페이스를 제공하는 API 세트를 포함할 수 있다. 대안으로, 요구 핸들러(1406)는 하나의 운영 체계에서 수신된 요구를 다른 운영 체계에 의해 처리되는 API 호출로 변환하는 미들웨어 코드를 포함할 수 있다. 따라서, 본 명세서에서 사용되는 바와 같이, 요구는 실제 상태 머신 처리가 발생하거나 데이터 구조 및 클래스가 제공되는지에 관계없이, 요구 핸들러를 통해, 요구된 행동이 일어나게 한다.
이러한 방식으로, (다른 메커니즘 중에서) 애플리케이션은 새로운 요구를 통해 변경가능 객체들을 구성하고, 이들에 값을 설정하고, 이들을 사용하고, 이들에 대한 값의 설정을 계속하고, 이들을 계속 사용할 수 있다.
다음은 애플리케이션이 솔리드 칼라의 브러시(scb)를 생성하고, 브러시가 솔리드 칼라(red)를 갖도록 수정하고, 브러시를 이용하여 버튼의 백그라운드를 적색으로 착색하는 방법의 일례이다:
값의 "사용"이라는 개념은 특정 의미를 갖는데, 즉 값들은 소정의 조건 하에서 사용되는 것으로만 간주된다. 이러한 조건은 값이 Property System 속성 내에 설정될 때, 값이 보다 복잡한 변경가능 객체 내의 서브 객체로서 사용될 때, 및 값이 DrawingContext 명령 등에서 사용될 때를 포함한다. 시스템 확장자들은 "사용"으로서 적격이고 객체의 변경가능 상태를 수정하는 변경가능 객체를 사용하는 다른 인스턴스들을 쉽게 정의할 수 있다는 점에 유의하자.
이러한 적격 사용 종류들 중 하나에서 값이 사용될 때, 사용자 모델의 관점에서 이 값의 복제본(clone)이 만들어지고, 그 복제본은 거짓으로 설정된 IsChangeable 속성을 가진다. 실제로 복제본은 반드시 생성되는 것은 아니며, 하나가 생성될 때 그 복제본은 반드시 깊은(후술되는 바와 같이 객체 계층구조에서) 것은 아니라는 점에 유의한다. 그럼에도, 모델의 시각에서는 복제본이 생성되고 있는 것으로 간주하는 것이 적절하며, 따라서 본 명세서에서 사용되는 바와 같이 복제본의 개념은 실제로 생성되는 복제본, 부분적으로 생성되는 복제본, 및/또는 반드시 생성되지는 않더라도 모델의 관점에서 국부적으로 생성되는 복제본을 포함 한다. 복제본은 실제로 사용되는 것이며, 디폴트로 복제본은 수정될 수 없다.
위에 나타난 바와 같이, 변경가능 객체는 또한 Copy() 및 MakeUnchangeable()을 포함하는 메소드를 갖는다. Copy() 메소드에 대한 명시적 호출은 변경가능 객체의 사본을 생성하는데, 이 사본의 IsChangeable 속성은 참으로 설정된다. 이 호출은 메소드가 호출된 객체를 변경하지 않는다. MakeUnchanbeable() 메소드는 어느 변경가능 객체에서나 호출될 수 있으며, IsChangeable 속성이 거짓이 되도록 수정한다(아직 거짓이 아닌 경우 호출은 효과가 없다).
위의 메커니즘은 속성을 대체하기 위한 패턴을 용이하게 한다. 변경가능 객체를 변경하기 위하여, IsChangeable 속성 값은 참일 필요가 있다. 객체의 적격 이용은 변경가능하지 않은 복제본을 생성하므로, 그 객체는 Copy() 메소드를 통해 복사되고, 변경되고, 다시 사용되는 것을 필요로 한다. 이것은 기존의 초기 객체를 원본의 수정된 사본인 새로운 개체로 효과적으로 대체한다. 그 예는 후술된다. 사용중인 변경가능 객체가 사용되었던 객체이며, 따라서 위의 정의에 의해 IsChangeable 속성이 사용시 거짓으로 설정되므로 변경가능 객체가 아니라는 점에 유의한다. 따라서, 이 변경가능 객체는 수정되지 않고, 오히려 하나의 변경가능 객체가 복사되고 대체된다. 변경가능 객체에 대해, 프로그래밍 관점에서 일반적으로 훨씬 더 바람직한 타입들의 단일 세트만이 존재한다는 점에 유의한다. 또한, 진정한 변경가능성은 후술되는 바와 같이 추가 속성들에 의해 제공된다.
전술한 바와 같이, 브러시를 생성하고, 수정하고, 사용하는 것은 간단하다. 드로잉 동작에서의 간단한 사용 예가 아래에 설명된다:
위의 명령들의 실행은 하나의 적색 사각형 및 하나의 녹색 사각형을 드로잉한다. 결과적으로 'scb'가 그의 각각의 사용시에 복제된다는 점에 유의한다.
칼라가 하나의 스톱에서 다른 스톱으로 (예를 들어 선형으로) 변하는 리니어 그래디언트 브러시(lgb)를 사용하는 보다 복잡한 구성이 아래에 설명된다:
여기서, 프로세스는 값들(GradientStops)을 구축하고, 보다 복잡한 값들의 정의로 이들을 사용하는 것이다.
버튼(Btn)의 백그라운드의 불투명도(0에서 1의 범위일 수 있다)를 0.4로 변경하는 것을 지향하는 또 하나의 예를 고려하자. 이러한 특정 사용에 있어서, Background은 IsChangeable 속성이 참 값으로 설정된 객체 내에 복사되며, 백그라운드는 수정되고, 다시 설정된다.
마지막 행의 "Btn.Background"에 대한 할당은 들어왔을 수 있는 임의의 상속 또는 속성 시트 값을 절단(sever)한다.
객체 계층 구조 내에서 얕은 수정들보다 깊은 수정들도 사용자에게는 상이하게 보이지 않는다:
Copy()는 개별 GradientStops 상에서가 아니라 최상위 레벨 객체 상에서 호출되는 것만이 필요하다는 점에 유의한다. 이것은 시스템이 참인 IsChangeable 속성을 가진 객체의 서브 객체들이 액세스될 때 그들 자신을 참과 동일한 IsChangeable를 갖도록 설정하는 것을 보장하기 때문이다.
도 15는 새로 생성될 때 참인 IsChangeable 속성을 갖는 것에서 시작하는 기본 사용에 있어서의 변경가능 객체의 상태들을 나타내는 상태도이다. 일반적으로, 실선 화살표는 현재 상태에서 목표 상태로 전이하는 객체의 상태를 나타내며, 점선 화살표는 객체를 동일하게 유지하지만 목표 상태의 새로운 객체를 생성하는 동작을 나타낸다. 이 상태도에는 2가지 상태가 있으며, 전이는 Copy() 또는 MakeUnchangeable()이 호출될 때, 그리고 전술한 바와 같이 사용으로서 적격인 방식으로 객체가 사용될 때 발생한다. 어느 한 상태에서 Copy()를 호출하는 것은 참으로 설정된 IsChangeable 속성을 가진 새로운 값을 생성하며, MakeUnchangeable()의 호출은 거짓으로 설정된 IsChangeable를 가진 목표 값을 생성한다는 점에 유의한다.
위의 설명은 단지 2가지 상태, Copy() 및 MakeUnchangeable() 메소드들 및 Changeable 값의 "사용" 개념을 통해 기본적인 사용을 설명하는 간단하고 일관성있는 모델을 제공한다. 그러나 변경과 관련하여, 위의 수정 예는 대체의 개념, 즉 기존 항목을 복사하고, 그것을 적절히 변경하고, 그것을 다시 복사하는 개념에 기초한다. 이것은 수정할 속성에 대한 경로를 찾기 위한 소정의 메커니즘을 유지해야 하는 프로그래머의 추가적인 부담은 물론 힙 할당(이것은 이루어질 변경이 얼마나 깊은지, 그리고 객체 자체가 얕은 복제본들에 대해 얼마나 넓은지에 따라 잠재적으로 중요할 수 있다)을 내포한다.
본 발명의 일 국면에 따르면, 값들의 진정한 가변성의 개념에 대한 지원을 추가하기 위하여, 타입 UseStatus의 StatusOfNextUse라고 하는 또 하나의 속성이 모델에 추가된다. 단일 속성 모델에서 가변성을 방해하는 기초적인 문제는 값의 적격 사용이 거짓인 IsChangeable 속성을 가진 결과 값을 무조건적으로 생성한다는 것이라는 점에 유의한다. StatusOfNextUse 속성은 이러한 문제를 해결한다.
디폴트로, StatusOfNextUse 속성은 UseStatus.Unchangeable이지만, UseStatus.ChangeableCopy로 설정될 수 있으며, 이에 따라 이 속성이 설정된 값의 사용은 참인 IsChangeable 속성을 가진 복제 객체를 생성한다. 결과적으로, 객체 값은 어떠한 추가적인 힙 할당 없이 적절히 수정될 수 있다.
또한, 사용중인 값들은 이 모델에서 변경될 수 있기 때문에, 간단한 변경 이벤트를 통해, 이러한 변경이 발생할 때 통지가 제공된다. 더욱이, 객체는 더 이상 변경가능 객체가 아니므로, 컨텍스트 친화성이 UIContext 멤버를 통해 제공된다. 객체가 변경가능할 때, 객체는 공백 값을 갖는다는 점에 유의한다. 그렇지 않은 경우, 객체는 이 객체가 생성된 UIContext에 속한다. 결과적인 Changeable 클래스 정의는 다음과 같다:
간단하고 얕은(shallow) 가변성의 상기 예는 불투명도가 변경될 때마다 실행해야 하는 코드와 함께 브러시 상의 불투명도를 변경하기 위한 요건을 설명하였다. 대조적으로, StatusOfNextUse 속성에 기초한 가변성 메커니즘에서, 먼저 Btn.Background 자체는 참인 IsChangeable 속성 값을 갖는다:
위에서는 UseStatus.ChangeableCopy의 StatusOfNextUse를 가진 값을 사용(적격 사용)했으며, 따라서 결과 자체는 변경가능하다. 일단 셋업되면, 프로그래머는 다음의 예에서와 같이 필요에 따라 수정을 행할 수 있다:
프로그래머는 필요한 만큼 자주 이러한 수정을 행할 수 있으며, 이러한 수정은 후속 설정에 대한 어떠한 객체 할당도 없이 직접 발생할 수 있다.
위의 예는 Btn.Background가 어떻게 처음 존재하게 되었는지, 따라서 그의 사본이 Copy() 메소드를 통해 만들어져야 하는지를 설명하지 않는다는 점에 유의하자. 프로그래머가 수정될 백그라운드를 생성하기를 원하는 계획적인 가변 상황에서, 이를 행하는 최선의 방법은 아래의 예에서와 같이 직접 행하는 것일 수 있다:
이때, 프로그래머는 브러시가 UseStatus.ChangeableCopy와 동일한 StatusOfNextUse로서 초기에 생성되었으므로 필요할 때마다 불투명도(Btn.Background.Opacity=...)를 지정할 수 있다.
변경 기반 모델이 아닌 대체 기반 모델의 사용은 위의 예가 주어질 때 특히 어려운 것은 아니라는 점에 유의해야 한다. 이것은 변경이 제1 레벨에서 만들어지고, 변경하는 것이 아니라 항상 대체하는 것이 엄청나게 비용이 많이 들어 보이지 않을 수 있기 때문이다. 실제로, 이것은 제한된 가변성을 원할 때 유효한 기술이다. 그러나, 객체보다 깊은 값들에 대해 변경이 만들어질 때에는 변경 모델이 명백히 우수하다.
이러한 보다 깊은 가변성의 예로서, 프로그래머가 제7 스톱(lgb.Stops[6])의 칼라를 변경하기를 반복적으로 원하는 경우의 LinearGradientBrush(lgb)를 고려하자. 프로그래머는 변경가능 버전을 Btn.Background 내에 설치하기 위해 위와 동일한 명령을 사용할 수 있다:
이후, 프로그래머는 원하는 변경을 반복적으로 행할 수 있다:
프로그래머는 또한 "lgb" 변수에 한번 액세스하고, 이 변수를 딴 곳에 저장한 후 이 변수 내에 반복적으로 설정할 수 있는데, 이것은 매우 효율적이다.
도 16은 추가된 StatusOfNextUse 속성에 의해 표현된 추가 상태를 가진 도 15의 상태도의 확장이다. 도 16의 기본 상태도는 2개의 상태 및 7개의 전이를 갖는 반면, 가변성 상태도는 3개의 상태 및 11개의 전이를 가지므로, 모델은 단지 약간 더 복잡할 뿐이다. 도 15에서 볼 수 있듯이, 중요한 추가는 (StatusOfNextUse==ChangeableCopy) 상태, 및 이 상태 중의 "Use" 전이인데, 이 전이는 참으로 설정된 IsChangeable 속성 값을 갖는 새로운 사본을 생성한다.
도 15에서와 같이, Copy() 메소드의 호출은 참으로 설정된 IsChangeable 속성을 가진 새로운 값을 생성하며, StatusOfNextUse 속성이 Unchangeable로 설정되게 한다. 유사하게, MakeUnchangeable() 메소드의 호출은 거짓으로 설정된 IsChangeable 속성을 가진 목표 값을 생성한다. 가변성을 통해 유연성이 추가되었지만, 이 상수들은 변경되지 않았다는 점에 유의할 것이다.
후속 수정들이 진정으로 제대로 정의되지 않거나 명시적으로 불허용되기 때문에, ChangeableCopy와 동일한 StatusOfNextUse로서의 사용이 허용되지 않는 몇몇 상황이 존재한다. 그 예는 공유 디폴트 스타일 시트 내의 값들을 수정하려는 시도, 또는 논-로컬(non-local) 속성 엔진 속성들의 설정을 포함한다. 이러한 상황에서, 그러한 사용을 허용하지 않는 서브 시스템은 예외를 발생시키도록 선택하거나, 값 자체를 변경 불가능한 것으로 만든다. 프로그래머에게 무엇이 발생했는지를 알리고, 따라서 나중의 혼란을 피할 수 있도록 하는 보다 명백한 표시로서 예외가 생성되는 것이 권장된다.
또한, 변경가능 객체가 변경 불가능 객체로 될 수 없는 상황들이 존재한다. 그 예는 VisualBrush(전술한 미국 특허 출원 번호 10/402,268에 설명된 바와 같음)를 포함하는데, 여기서 기반 비주얼(underlying visual)은 변경으로부터 제한될 수 없으며, 따라서 VisualBrush가"변경 불가능"이라고 말하는 것은 무의미하다. 애니메이션 및 비디오 데이터(이들은 시간에 따라 변하므로)도 그 예이다. 이러한 객체들 상에서 MakeUnchangeable()를 호출하려는 시도는 예외를 발생시키거나, 보다 나쁘게는 객체의 일부는 변경 불가능하게 되지만 다른 부분은 그렇게 않게 되므로 객체가 나쁜 상태가 되게 할 수 있다. 이러한 문제는 또 하나의 속성, CanMakeUnchangeable을 통해 회피할 수 있다. 이 속성이 참 값을 리턴하는 경우, MakeUnchangeable()은, 이들 호출 사이에 객체에 대한 변경이 발생하지 않는다면 성공이 보장된다.
StatusOfNextUse와 CanMakeUnchangeable 사이에 가끔 발생하는 시맨틱들의 충돌이 존재한다. CanMakeUnchangeable이 거짓인 경우, StatusOfNextUse에 대한 UseStatus.Unchangeable의 값은 그 다음 사용이 변경 불가능일 수 없으므로 실제로 이해되지 않는다. 따라서, CanMakeUnchangeable이 거짓일 때 StatusOfNextUse가 질의되는 경우, 이것은 UseStatus.Unchangeable를 리턴하지 않는다. 대신에, 그와 달리 이것이 UseStatus.Unchangeable를 리턴했을 경우, UseStatus.ChangeableCopy를 리턴한다.
위에서는 변경가능(IsChangeable이 참) 객체의 모든(적격) 사용이 그 객체의 사본을 만들고, StatusOfNextUse의 값에 따라 그 사용 자체가 변경가능하거나 가능하지 않을 수 있는 모델을 제공한다. 위의 모델이 제공하지 않는 것은 여러 곳에서의 하나의 값의 사용, 및 그 값에 대한 공유 참조(shared reference)의 유지이다. 예를 들어, 위의 모델에서, 프로그래머는, LinearGradientBrush를 생성하여, 이것을 2개의 버튼 제어 상에서 사용한 후 양 제어에 효과를 주기 위해 LinearGradientBrush를 한번 변경할 수 없다. 오히려, 프로그래머는 이것을 두번 사용하고, 제어들로부터 브러시를 회수한 후 각각을 독립적으로 설정해야 한다. 일반적으로, 이 모델은 프로그래머에게 가장 많이 예측되거나 가장 놀랍지 않은 것으로 판명되었으나, 추가 기능들이 바람직한 시나리오들이 존재한다.
이러한 시나리오 중 하나는 애니메이션에서인데, 여기서는 프로그래머가 동일 타임라인에 각각 응답하는 n개의 요소를 가진 장면을 생성하기를 원할 경우, 이 타임라인은 n번 복제되고 BeginIN()으로 n번 요청되어야 한다. 프로그래밍 모델의 편리성은 물론 성능 및 효율성의 관점에서 보다 양호한 방법은 단일 타임라인(timeline)에 대한 참조를 공유하고, 그 위에서 BeginIn()을 호출하고, 적당한 때에 그것을 전파하는 것이다.
이러한 시나리오를 가능하게 하기 위하여, 제3의 값, ChangeableReference에 UseStatus 열거가 제공된다. UseStatus는 이제 다음과 같다:
UseStatus.ChangeableReference로 설정된 StatusOfNextUse를 가진 변경가능 객체가 사용될 때(적격 방식으로), 이 값은 더 이상 복사되지 않는다. 오히려, 기존 값에 대한 참조가 전달되고, 그 값(또는 이전에 또는 후속적으로 전달된 임의의 참조들)에 대한 후속 수정들이 사용의 결과에 영향을 미친다. 즉, 변경가능 값은 이제 잠재적으로 어느 수의 사용들에서든지 공유된다.
다음은 요소 레벨 사용(element level usage)의 예이다:
위의 예에서는, 2개의 사각형, 즉 하나의 적색 사각형 및 하나의 청색 사각형을 생성하는 간단한 드로잉 동작이 설명되어 있다:
이것은 원하는 행동이다. 그러나, 프로그래머가 대신에 브러시가 공유되고 변경가능하기를 원했다면, 다음의 명령들이 사용될 수 있다:
여기서, 두 사각형은 녹색이다. 후에 칼라가 변경되는 경우, 예를 들어 scb.Color=Colors.Yellow인 경우, 두 사각형은 황색이 된다. ctx.DrawRectangle(...)은 즉석 모드 드로잉 명령인 것으로 보이지만, 실제로는 유지되고 후에 표시될 표시 리스트/메타파일을 구축한다는 점에 유의한다.
사용자 모델 관점에서, ChangeableReference 모드는 변경가능 객체를 사용하고 있는 당사자들이 그 값에 대한 임의의 변경을 통지받는 것을 보장한다. 이것은 다른 이벤트와 같이 멀티캐스트 델리게이트(multicast delegate)인 "Changed" 이벤트를 통해 행해진다. 구현을 위해, 시스템은 단일 통지 싱크(sink)에 의한 다수의 사용이 각각의 사용에 대해 이 싱크를 통지하지 않는 것을 보장해야 한다. 또한, 클린업 메커니즘들은 항목들을 제거할 때, 싱크에 연결된 사용들이 끝날을 때 그 싱크만을 제거하도록 요구사항들을 갖는다. 이를 위한 하나의 방법은 카운트 델리게이트를 참조하는 것이다. 현재의 구현은 사설 데이터 구조, 예를 들어 RefCountedMulticastEventHandler를 통해 이러한 요구사항을 달성할 수 있다.
도 17은 도 15 및 16에 기초하나 ChangeableReference 상태(StatusOfNextUse 속성 내의 또 하나의 설정을 통해)가 추가된 상태도이다. 본 발명의 일 국면에 따르면, ChangeableReference 상태 및 이 노드의 Use 전이는 사본을 만들지 않음에 유의할 것이다. 오히려, 적격 사용이 다음 사용 속성의 상태를 변경가능 참조 상태로 유지하여 진정한 가변성을 제공한다. 또한, 도 17은 도 15 및 16보다 복잡한 반면, Copy() 및 MakeUnchangeable() 메소드의 행동은 일정하게 유지되는데, Copy() 메소드는 여전히 참의 IsChangeable 속성 및 Unchangeable의 StatusOfNextUse 속성을 가진 새로운 값 객체를 생성하며, MakeUnchangeable() 메소드는 여전히 거짓의 IsChangeable 속성을 가진 목표 값 객체를 생성한다는 점에 유의한다.
단일 타입들의 세트의 이점과 함께, 본 발명은 프로그래머에게 커다란 유연성을 제공한다는 점에 유의해야 한다. 예를 들어, 애플리케이션에 의해 구축되는 대부분의 값들은 통상 변경 불가능한데, 이는 변경 불가능한 값들이 자원은 보다 적게 소모하기 때문이다. 그러나 전술한 바와 같이, 가변성이 이용되어, 프로그래머에게 고성능으로 값들, 특히 깊은 값들을 변경할 수 있는 강력하고 직관적인 방법을 제공할 수 있다. 도 17에 나타나지는 않았지만, 새로운 타입이 생성되는 상태(참의 IsChangeable 속성, Unchangeable의 StatusOfNextUse 속성)는 하나의 가능한 디폴트 상태일 뿐이라는 점도 유의한다. 따라서, 대체 실시예에서, 타입은 생성에 따르는 또 하나의 상태, 예를 들어 가변 값들을 디폴트로 하는 참의 IsChangeable 속성, ChangeableReference의 StatusOfNextUse 속성을 가진 상태에 있을 수 있다.
본 발명의 동작의 설명으로 돌아가면, 본 발명은 도트 다운(dotting-down)으로 지칭되는 객체의 깊은 속성들의 처리시 상당한 이점을 제공한다. 예를 들어, 다음을 고려하자:
형상 객체 'g'로의 깊은 액세스는 도트 다운으로 지칭되는 것의 일례이다. 속성들(Geometries, [12], Figures, [2], Segments, [0], 및 Points)에 대한 액세스는 세터(setter)가 아니라 속성 게터(property getter)를 호출하는 것이며, [17]은 세터를 호출하는 유일한 속성 액세스라는 점에 유의하자. 프로그래밍 언어들은 일반적으로 보다 깊은 속성 값을 설정하기 위한 속성에 대한 액세스와 보다 깊은 값을 판독하기 위한 액세스를 구별할 수 없다.
변경 불가능 객체로부터 도트 다운이 시작될 때, 로컬 멤버 변수가 액세스된다. 그 예는 "ChangeableValue" 속성의 사용을 통해 변경가능하게 되지 않은 요소에 액세스하는 것을 포함한다.
변경가능 객체로부터 속성 취득이 발생할 때, 그 결과 값도 변경가능하여, 변경될 수 있다. 이 때문에, 부모 상의 속성 게터는 이미 변경가능한 경우 서브 객체를 직접 리턴하거나, 서브 객체의 얕은 복제본을 만들고, 이것을 로컬 멤버로 설정하여 리턴한다. 이러한 속성들은, 힙 할당을 요구하지 않는다는 면에서, 자유롭게 우서적으로 실행되어 얕은 복제본들을 할당하고 지정한 후 위의 코드를 만든다는 점에 유의하자.
본 발명의 일 특징은 온-디맨드(on-demand)인, 얕은 복제가 필요할 때에만 수행된다는 것이다. 이것은 공유를 최대화하고 힙 할당을 최소화하며, 힙 할당 없이 수정을 허용하고, 사용자 모델에 복제의 개념을 강요하지 않는다. 이것은 보다 깊은 트리에서, 그리고 3차원에서 동작할 때 더욱 중요해진다. 이 때문에, Copy() 메소드는 깊은 복사의 환영(illusion)을 제공하지만, 실제로는 먼저 얕은 복사본만 을 만든 후, 필요에 따라 천천히 보다 깊은 사본을 만든다. 이러한 도트 다운은 상당한 성능 향상을 제공한다.
본 발명의 일 국면에 따르면, 변경가능 객체 상의 또 하나의 속성(일반적으로 애플리케이션에게 보이지 않음)은 변경가능 객체가 변경된 이벤트(타입 EventHandler)를 갖는다는 점이다. Changeable(변경가능 객체)의 속성이 변경될 때, 그 변경가능 객체 상의 Changed 델리게이트가 호출되어, 전송자(sender)로서 변경가능 객체를 변경한다. 도트 다운을 통해 얕은 복제본을 만드는 동작은 변경된 이벤트 핸들러를 얕은 복제본 내로 푸시 다운시킨다. 이것은 보다 깊은 요소들 상에 후속 변경이 발생하고 적당한 이벤트 핸들러가 셋업되는 것을 허용한다. 속성 시스템이 아닌 클라이언트가 이 시스템을 사용하고 통지를 위해 등록할 수 있도록 Changed 이벤트가 또한 존재한다는 점에 유의한다.
변경된 이벤트 핸들러에 대한 수정은 서브 객체 아래로 전파된다. 또한, 다른 변경가능 객체들을 수반하는 변경가능 객체 자체에 대한 수정들(예를 들어 변경가능 객체에 변경가능 서브 객체의 추가, 변경가능 객체의 제거 등)은 포함하는 변경가능 객체의 이벤트 핸들러가 반복적으로 오래된 객체로부터 제거되어 새로운 객체로 푸시되게 한다.
도 18 내지 도 23은 이 예에 대한 아래의 코드에 기초하여 얕은 복제(shallow-cloning) 및 도트 다운이 어떻게 동작하는지를 나타낸다:
도 18에 도시된 바와 같이, Button1 및 Button2는 동일한 리니어 그래디언트 브러시(1802)를 지시하는데, 이 브러시는 스톱 노드(1804) 및 아래에 계층적으로 배열된 지정 스톱들에 대한 칼라 및 위치 속성들을 갖는다. 다음 코드를 고려하자:
Btn1.Background=Btn1.Background.Copy();
이 코드의 실행은 리니어 그래디언트 브러시(1802)의 사본(1902)이 도 19에 도시된 바와 같이 생성되고 Button1에 의해 지시되게 한다.
LinearGradientBrush lgb = ((LinearGradientBrush)Btn1.Background);
lgb.Stops[1].Color = Colors.Orange;
위 코드의 실행은 IsChangeable==true를 가진 Changeable 객체의 Changeable 값을 가진 속성에 대한 액세스를 제공하는데, 이는 검색되는 것이 기록 가능한 것임을 보장한다는 의미이다. 도 20-22에 일반적으로 나타난 바와 같이, 이 코드의 실행은 (1) 개별 스톱들 각각을 지시하는 또 하나의 스톱 노드(2004)가 계층 구조 에 삽입되고(도 20); (2) 제2 스톱 노드(도 20 및 21에 2010으로 표시되고 아래에 "Blue" 속성을 가진 스톱 노드 [1])의 사본(2110)(도 21)이 생성되어, 이 사본의 부모인 이전에 복사된 스톱 노드(2004)가 그 자식으로서 (청색 속성의 오리지날 스톱 노드(2010) 대신) 이 사본(2110)을 갖게 하며; (3) 도 20에 나타난 바와 같이 이 노드(2110)의 청색 속성을 오렌지색으로 변경한다. 오렌지색은 도면에서 다이아몬드 모양에 의해 표시되는 값 타입이며, 후속 변경은 도 23의 칼라 Red에 대한 변경과 같이 어떠한 할당도 초래하지 않는다는 점에 유의한다.
변경 불가능 상태에 있을 때, 변경가능 객체는 임의의 컨텍스트로부터 판독되고 임의의 컨텍스트에 기록될 수 있다. 변경가능 상태에 있는 경우, 구축시에 결정되는 UiContext는 이 컨텍스트로부터만 액세스를 허용하도록 변경가능 객체와 연관되는 데 사용될 수 있다. MakeUnchangeable이 나중에 호출되는 경우, 컨텍스트는 공백이 된다. 또한, 언제든지 변경가능 객체의 Copy()가 생성되고, 새로운 사본은 소스 변경가능 객체의 컨텍스트로부터가 아니라 호출자로부터 UIContext를 취득한다. API는 변경 불가능할 때 공백인 변경가능 객체 상에 UIContext get-only 속성을 제공한다. 이 속성은 공개여서, 애플리케이션은 주어진 객체가 액세스될 수 있는지를 알 수 있다.
구축자에게 전달된 공백으로 구축된 변경가능 객체는 공백 UIContext로 정의된다. 변경가능 객체가 공백 UIContext를 갖고, IsChangeable 속성이 참으로 설정되는 경우, 애플리케이션은 발생할 수 있는 임의의 가능한 스레드 충돌 문제를 관리해야 한다. 이 경우, 시스템은 다수의 컨텍스트로부터의 동시 액세스를 방지하 지 못한다.
변경가능 객체가 그 안에 다른 변경가능 객체를 삽입하려고 시도하고(예를 들어 리니어 그래디언트 브러시 내에 그래디언트 스톱을 설정), UIContext들이 매칭되지 않는 상황이 발생할 수 있다. 예를 들어, LinearGradientBrush lgb가 A의 UIContext를 갖지만, GradientStop gs가 B의 UIContext, 및 ChangeableReference와 동일한 StatusOfNextUse 양자를 갖는 상황을 고려하자. lgb 내에 gs를 설정하려는 시도는 예외를 발생시키게 되는데, 이는 그 시도가 허용되지 않는 UIContext들의 혼합 시도이기 때문이다.
변경가능 객체에 대한 변경이 만들어질 때, 변경된 이벤트가 발생하며, 변경가능 객체는 이벤트 핸들러에 대해 전송자 객체로서 제공된다. 그러나, 객체를 전송할 때 실제로 변경되는 것이 바람직하지 않으며, 다른 객체를 전송자로서 갖는 것이 보다 도움이 되는 상황들이 존재한다. 그 예는 애니메이션화된 객체인데, 여기서 애니메이션(그 자체는 변경가능)은 그의 애니메이션 행동을 설명하는 타임라인(종종 클록으로 지칭됨) 상에 유지된다. Pause()와 같은 이벤트가 애니메이션이 아니라 타임라인 상에 발생하지만, 일반적으로 애플리케이션은 애니메이션이 중지되는 것을 알기를 원한다.
변경가능 객체들의 체인 상에 변경된 이벤트를 점화(fire)하는 것과 같은 다양한 솔루션이 가능하다. 이것은 어디서 중지할 것인지를 결정하는 것을 포함하여 많은 문제를 발생시키는데, 이는 아무것도 이벤트를 수신 및/또는 사용하지 않고 변경가능 객체들이 설계에 의해 그들의 부모를 알지 못하지만 오히려 일반적으로 변경의 이벤트에서 무엇을 통지할지만을 알 때에도 많은 이벤트들이 점화되고 통지 폭풍이 발생하게 한다. 변경가능 객체들이 그들의 부모를 추적하는 스킴을 갖는 것은 추가적인 저장 및 부기(bookkeeping)를 필요로 한다. 그럼에도 이러한 솔루션이 구현될 수 있다.
또 하나의 솔루션은, 전송자가 실제로 변경된 내부 변경가능 객체가 아니라 변경가능 객체이도록 변경가능 객체를 구현하는 것이다. PropagateEventHandler는 그것을 수신하는 핸들러를 푸시 다운하는 것이 아니라 그 핸들러를 따로 저장하고, 호출시 저장된 핸들러를 호출하지만 변경가능 객체를 전송자 독립 변수로서 갖는 새로운 로컬 핸들러를 생성하도록 구현된다. 새로운 로컬 핸들러는 변경가능 자식들 상의 PropagateEventHandler로 푸시 다운된다. 이러한 기술은 모든 이벤트 핸들러를 가로채어(intercept), PropagateEventHandler가 거짓으로 호출될 때(핸들러가 제거되어야 할 때) 정확하게 처리될 것을 요구하며, 따라서 부기가 행해질 것을 요구한다는 점에 유의하자.
이러한 솔루션은 명시적인 BeginChange/EndChange 스코핑 메커니즘을 갖지 않으므로 예외 앞에서 보다 간단하고 강력해진다는 점에 유의한다(어떠한 양식(modality)도 수반하지 않으며, 스킵될 수 있는 어떠한 EndChange()도 예측치 못한 예외에 의해 전달되지 않기 때문이다). 그러나, Begin/EndChange는 얕은 복제본들이 동결되고 시스템이 기록 모드에 있지 않은 때 객체들의 "게터들"이 이들이 취득하고 있는 값들의 얕은 복제본을 만들 필요가 없게 하도록 존재하였다. 그렇지 않은 경우, 동결된 값들은 기록 모드에서 그들로 이루어진 얕은 복제본을 취득한다. 결과적으로, 트리는 Begin/EndChange에서보다 더 자주 폭발하며, 절대적으로 어떠한 설정도 수반되지 않고, 단지 취득만이 수반될 때 그렇게 할 수 있다. 그럼에도, 게터가 시작할 변경 불가능 값 상에 호출되는 경우, 게터는 얕은 복제본을 만들지 않는다(이것은 변경가능 값 상에 호출되는 게터와 다르며, "get"을 통해 얻어지고 있는 값은 복제 동작이 발생하는 곳인 변경 불가능 값이라는 점에 유의한다).
예를 들어, Btn.Background.Opacity를 액세스하고, Btn.Background가 변경 불가능일 때(예를 들어 디폴트에 의해), 복사가 이루어지지 않는다. 대신에, "Btn.Background = Btn.Background.ChangeableValue" 등이 발생할 때 복사가 이루어지는데, 이는 복사 비용이 사용되는 경우에만 발생한다는 것을 의미한다. 즉, 값을 변경하려는 의지가 표현되지 않은 경우, 임의의 "취득(getting)"은 복사 비용을 발생시키지 않는다. 값들이 그들의 "최종 생성 복제본(last created clone)"의 개념을 유지하는 경우, 그 복제본은 객체가 복제본이 만들어진 이후 변경되지 않는 한(이러한 변경은 단지 캐시된 복제본을 방출함) 객체의 사용시 전달될 수 있다는 점에 유의한다. 이것은 보다 많은 공유를 허용한다. 또한, 제어 구현자들은, 이 패턴에 참여함으로써 패턴이 사용자에게 유용한 것만큼 과도하게 부담을 갖지 않는다는 점에 유의한다. 이와 유사하게, 타입 확장성이 제공되는 경우, MediaType의 기록은 너무 복잡하지 않아야 한다.
제어 구현자는 임의의 다른 값의 경우와 같이 변경가능 객체를 처리하는 모델을 제공받는다. 예를 들어, 다음의 코드는 타입 Brush의 AlternateBrush 속성을 가진 Grid 제어를 제공한다:
이것은 속성 시스템에 참여하는 일반적인 속성과 동일하다는 점에 유의한다. 이것은 WriteLocal이 변경가능 클래스로부터 도출되는 깊은 속성들에 대해 특수한 처리(handling)를 행하기 때문이다.
변경가능 타입 구현자는 변경가능 객체(예를 들어 속성)를 수정하는 모든 것에 대해 1 라인 프리앰블 및 1 라인 포스트스크립트를 필요로 한다. 또한, 변경가능 객체(예를 들어 속성 게터)의 상태를 액세스하는 객체들에 대해 간단한 1 라인 프리앰블이 필요하다. CloneCore(), MakeUnchangeableCore(), PropagateEventHandlerCore(), PropagateEventHandlers()의 구현이 필요하며(뒤의 3 개는 다른 변경가능 객체를 속성으로 갖는 타입에 대해서만 필요하다는 점에 유의한다), Copy()에 대한 타입 안전 랩퍼(typesafe-wrapper)도 필요하다.
간단한 변경가능 타입(이것은 그의 서브 타입들 중 어느 것도 변경가능 타입이 아니라는 점에서 단순화된다)인 GradientStop의 예(인공)를 포함하는 다음의 예는 참조된 프로토타입으로부터 나온 것이다. 실제로, 애니메이션 컬렉션(그 자체는 변경가능)을 포함하는 어떤 것도 더 복잡하다는 점에서 매우 적은 변경가능 객체들이 단순화된다:
다음은 보다 복잡한 변경가능 타입(그의 서브 타입들 중 일부, 즉 GradientStops 자체가 변경가능이기 때문)인 LinearGradientBrush의 예이다:
변경가능 객체 모델은 공개 부분과, 확장자(extender) 및 호스터(hoster)가 볼 수 있는 것인 부분으로 나뉜다. 이것들은 이러한 타입들을 사용하는 컴포넌트에 대해 간단하다는(strightforward) 점에 다시 유의한다.
StatusOfNextUse에만 의존하는 변경가능 객체의 적격 사용 행위는 모든 상황에서 정확하게 이루어지는 것은 아니라는 점에 유의할 것이다. 일반적으로, 문제는, 변경가능 객체(브러시, 비디오 데이터 등)가 요소 속성 내에 지정될 때 그 변경가능 객체는 적격으로 사용된다는 점이다. 애니메이트 변경가능 객체(비디오 데이터 등과 같으나 임의의 애니메이션도 됨)의 경우, "사용" 행위는 복제본을 생성하는데, 이는 정확하고 예측되는 행동이다. 그러면, 요소들의 OnRender() 메소드가 호출될 때, 일반적으로 OnRender() 구현이 예를 들어 DrawingContext.DrawVideo(비디오 데이터, ...)를 통해 값을 DrawingContext 내로 푸시한다. 이러한 DrawingContext로의 호출은 또한 변경가능 객체(이 경우 비디오 데이터)를 "사용"하며, 결과적으로 다른 복제본이 생성된다.
변경가능 객체가 이러한 방식으로 사용될 때의 양 행동은, 분리하여 고려될 때, 올바른 것이며 이해가 된다. 그러나 문제는 이들이 결합될 때, 제어의 구현자가 OnRender() 메소드가 호출될 때마다 적격 사용을 예측하지 못하며, 이러한 사용은 애플리케이션에 노출되지 않고, 사실 제거되어야 할 순전한 오버헤드이므로 실제로 그렇게 할 이익이 없다는 점에서 발생한다. 더욱이, 종속 애니메이션 및 독 립 애니메이션이 결합할 때, OnRender()는 자주 호출되며, 애니메이션들은 반복적으로 복사되는데, 이것은 올바른 행동이 아니다. ChangeableReference라고 하는 메커니즘은 실제로는 복사하지 않지만 대신에 사용되고 있는 값에 대한 참조를 취득만 하는 사용을 허용한다.
하나의 솔루션은 DrawingContext와 같은 엔티티와 DependencyObject 상의 DependencyProperties가 협조하는 것이다. 구체적으로, 제어의 DependencyProperty는 그 안에 값을 설정할 때 그것이 후에 사용되는 특정 컨텍스트가 그것이 그렇기를 원하는 경우 변경가능 객체가 ChangeableReference로서 취급될 수 있도록 할 것임을 표시하는 것이 필요하다. 그러면, DrawingContext 연산들은 예를 들면, 이들이 변경가능 객체 자체가 그것을 원할 경우 변경가능 객체가 ChangeableReference로서 취급되는 것을 "선호"한다는 것을 표시한다.
이 때문에, ChangeableHelper.UseChangeable에서 사용되는 Changeable.AllowChangeableReferenceOverride 및 열거 ChangeableUsageOverride라고 하는 부울 속성(Boolean)이 제공된다. 이 구현에서, UseChangeable은 ForceUnchangeable/NoOverride로의 참/거짓 맵핑과 함께 이전과 같이 동작한다. UseChangeable이 PreferChangeableReference와 함께 호출되고, 변경가능 객체가 IsChangeable==true를 갖고, 변경가능 객체가 AllowChangeableReferenceOverride==trus를 갖는 경우, 변경가능 객체의 사용은 ChangeableReference로서 일 것이다.
이것은 DependencyObject.SetValue()가 그가 유지한(수정가능할 때) 변경가 능 객체를 AllowChangeableReferenceOverride로 설정하게 하고, DrawingContext 메소드가 UseChangeable를 UsageOverridePreferChangeableReference와 함께 호출하게 함으로써 사용된다.
양 조건이 참이 아닐 때, Elt2.Prop=Elt1.Prop가 적격 사용에서 예측되는 대로 속성을 사용하고, 그것이 수정가능한 경우, 그것이 명시적으로ChangeableReference로 설정되지 않은 경우, UseChangeable는 PreferChangeableReference와 함께 호출되지 않을 것이므로 그것을 복사한다는 점에서 올바른 행동이 또한 발생한다는 점에 유의한다. DrawingContext의 직접 사용은 또한 적절히 기능하는데, 이는 그에게로 전송되고 있는 변경가능 객체가 AllowChangeableReferenceOverride를 갖지 않기 때문이다.
ChangeableReference를 서브 객체로 갖는 변경가능 객체가 존재할 때 얕은 복제본 및 깊은 복제본이 생성될 수 있다는 점에 유의한다. CloneCore 메소드가 새로운 얕은 "쉘(shell)"을 생성하여, 자식들 내로 더 깊게 가지 않고 그 자식들에 대해 지정할 때, 얕은 복제본이 동작해야 한다. 깊은 복제본에 대해, ChangeableCopy들 및 Unchangeable들의 트리의 경우, UnChangeable들로 복제하여, 방법을 따른 각각의 복제본 자체가 Unchangeable이 되게 함으로써(CanMakeUnchangeable이 참인 것으로 가정) 프로세스는 간단해진다. 이것은 최상위 레벨이 Changeable이고 그 아래의 모든 것이 Unchangeable인 깊은 복제본을 생성한다. 도트 다운은 다시 서브 요소를 수정가능하게 만든다는 점에 유의한다.
그러나 ChangeableReference가 존재하는 경우, 복제 동작은 효과적으로 수행 되어야 하지만, ChangeableReference로의 "Changeable" 경로에 대한 참조는 유지된다. 이것은 ChangeableReference로부터 통지가 있을 때 올바른 핸들러가 그것이 호스트되는 모든 곳에 대해 호출되도록 하기 위해 필요하다.
다음의 예를 고려하자:
여기서, LinearGradientBrush는 그의 스톱 컬렉션 및 단일 스톱이 있고 ChangeableReference가 생성될 때 생성된다. 브러시는 여러 장소에서 사용될 수 있고, ChangeableReference GradientStop에 대한 수정은 양 브러시에 효과를 주기 위해 필요하다.
변경가능 객체의 사용 예(유효 및 무효)
다음 섹션은 브러시, 펜 및 애니메이션 등과 같은 객체들이 프로그래머에 의해 제어되는 대로 변경될 수 있는 변경가능 클래스로부터 도출되는 객체들의 사용 및 조작의 개요를 제공한다. Changeable로부터 도출되는 클래스들은 적격 사용될 때 그들 자신의 변경 불가능 버전을 자동 구축함으로써 가변성을 시뮬레이션한다. 상술한 바와 같이, Changeable은 객체가 PropertySystem 속성으로 설정되거나 복합 Changeable 객체 내의 서브 객체로서 사용되거나 DrawingContext 명령 내에 사용될 때 적격 사용되는 것으로 간주된다.
이러한 객체들을 가진 애플리케이션을 개발할 때, 일반적으로 그래픽 및 매체 시스템 객체들이 생성되고, 설정되고, 사용되며, 수정되지는 않는다. 예를 들어, Button의 백그라운드를 설정하기 위하여, 프로그래머는 Changeable로부터 도출되는 SolidColorBrush를 사용할 수 있지만, 애플리케이션의 코스 상에서 버튼의 백그라운드를 다시 수정할 수는 없다. 다음은 일례이다:
이러한 방식으로 사용될 때, Changeable은 Rect 또는 Color과 같은 값 타입과 같이 행동한다. Changeable은 그의 목적지로 복사되며, 원본에 대한 변경은 사 용 값에 대한 변경에 영향을 주지 않는다. 그러나, 프로그래머가 객체를 사용한 후 객체를 수정하는 것이 필요할 수 있는 상황이 있다. 예를 들어, 사용자가 버튼을 클릭한 후 프로그래머가 이전 코드에서 버튼의 백그라운드를 변경하기를 원한다고 가정한다.
Changeable 패턴은 위의 것과 같은 다양한 상황의 요구를 만족시키기 위해 존재한다. 일반적으로, Changeable은 수정가능하거나 불가능한 값인데, IsChangeable 속성의 값으로 표시된다. IsChangeable이 거짓일 때 값을 수정하려는 시도는 예외를 발생시킨다. 더욱이, 수정될 수 있는 IsChangeable 객체들은 이들이 변경되거나 이들의 멤버들 중 어느 하나가 변경될 때 이들의 변경된 이벤트를 생성한다. 따라서, Changeable와 함께 동작할 때, Changeable이 언제 적격 사용되는지를 이해하는 것이 중요하다.
디폴트로, 변경가능 객체가 적격 사용될 때, 변경 불가능한 사본이 생성되고, 이 사본은 실제로 사용된다. 사본은 거짓의 IsChangeable 값을 갖는다. 아래의 코드는 예외가 발생하게 하는데, 이는 코드가 버튼의 백그라운드를 설정하는 데 사용된 myBrush의 수정 불가능한 사본을 수정하려고 시도하기 때문이다:
원 변경가능 객체의 수정은 사본을 갱신하지 않는다:
이 예에서 버튼의 백그라운드를 변경하기 위하여, 프로그래머는 수정된 브러시를 버튼의 백그라운드 속성으로 재할당(reassign)한다:
또한, 프로그래머는 Copy 메소드를 사용하여, 사용된 변경가능 객체의 수정가능한 사본을 검색(retrieve)할 수 있다. 검색된 사본은 효과를 갖기 위해 속성으로 재할당된다:
이것은 모든 상황에서 Changeable의 이상적인 행동이 아니기 때문에, 예를 들어, 프로그래머가 Changeable의 사용된 버전(작업 사본)을 수정하기를 원하는 r경우를 고려하면, 변경가능 클래스는 StatusOfNextUse 속성을 제공함으로써 프로그래머가 사용시 그것이 어떻게 행동할 것인지를 지정할 수 있도록 해준다.
StatusOfNextUse는 Changeable이 사용될때 어떻게 행동하는지에 대한 3개의 옵션을 제공한다:
Unchangeable: 이전 섹션의 예들에서 설명된 디폴트 행동. 변경가능 객체가 사용될 때, 이것은 원본 객체 대신에 사용되는 그 자신의 변경가능 사본을 생성한다. 프로그래머는 원본 객체를 계속 수정할 수 있으며, 사용된 버전(생성된 사본)은 원본 객체에 대한 수정에 영향을 받지 않으며, 수정될 수 없다. 사용된 버전을 수정하기 위하여, Copy 메소드가 수정가능 버전을 얻는 데 사용되며, 이 버전은 갱신되고, 새 버전이 사용된 버전을 대체한다.
ChangeableCopy: 변경가능 객체가 사용될 때, 이것은 원본 객체 대신에 사용되는 그 자신의 수정가능 사본을 생성한다. 프로그래머는 원본 객체를 계속 수정할 수 있으며, 사용된 버전(생성된 사본)은 원본 객체에 대한 수정에 영향을 받지 않지만, 수정가능하기도 하다. 사용된 버전은 Unchangeable의 StatusOfNextUse를 갖는다.
ChangeableReference: 변경가능 객체가 사용될 때, 이 객체는 자신에 대한 참조를 제공한다. 프로그래머는 원본 객체를 계속 수정할 수 있으며, 원본 객체에 대한 변경은 사용된 버전에 영향을 미치는데, 이들 객체는 동일한 객체이기 때문이다.
ChangeableCopy는 Changeable의 행동을 변경하여, 사용시 그 자신의 수정 불가한 사본(Unchangeable의 디폴트 설정의 경우)이 아니라 수정가능 사본을 생성한다. 다음의 코드(이전에 도시됨)는 예외를 발생시키는데, 이는 myBrush의 StatusOfNextUse 속성이 Unchangeable의 디폴트 설정을 갖기 때문이다.
그러나, 이 브러시의 StatusOfNextUse 속성이 ChangeableCopy로 설정되는 경우, 코드는 의도된대로 동작한다:
ChangeableCopy 설정은 또한 주 객체의 임의의 서브 객체들을 수정가능하게 유지한다. 다음 예에서, LinearGradientBrush에는 ChangeableCopy의 StatusOfNextUse가 주어진다. 결과적으로, LinearGradientBrush 및 그의 서브 객체들은 이들이 사용된 후에 수정가능하게 유지되며, 프로그래머는 이 예에서 GradientStop과 같이 객체에 포함된 임의의 변경가능 객체들의 StatusOfNextUse 속성을 설정할 필요가 없다:
ChangeableCopy의 StatusOfNextUse를 가진 변경가능 객체를 사용할 때, 프로그래머는 또한 사용된 Changeable의 버전에 대한 핸들을 유지하고 그 참조를 사용하여 객체를 수정할 수 있다. 다음 예에서, 사용된 LinearGradientBrush에 대한 참조가 검색되고, 버튼의 백그라운드를 수정하기 위해 사용된다:
ChangeableReference 설정은 Changeable의 행동을 변경하여, 사용시 그 자신에 대한 참조를 제공한다. 프로그래머는 원본 객체를 계속 수정할 수 있으며, 원 본 객체에 대한 변경은 사용된 버전에 영향을 미치는데, 이는 이들이 동일한 객체이기 때문이다. 다음은 일례이다:
브러시 및 펜
브러시는 평면을 채우는 방법을 나타내는 객체이다. 절대적인 방법으로 평 면을 채울 수 있는 것 외에, 매체 통합 계층의 브러시들은 또한 이들이 채우고 있는 객체의 크기에 대해 상대적으로 이들이 평면을 채우는 방식을 적합할 수 있다. 브러시 타입들의 예는 SolidColorBrush, VisualBrush(Visual을 참조할 수 있음), DrawingBrush(벡터 그래픽 자원을 참조할 수 있음), LinearGradient, RadialGradient, ImageBrush 및 NineGridBrush를 포함한다. 브러시 속성에 대한 디폴트 값은 아래에서 지정되며, 일반적으로 어떠한 동작도 유발하지 않는 값이다. 즉, 칼라는 투명 등을 디폴트로 한다. 또한, 애니메이션 컬렉션은 공백을 디폴트로 한다.
전술한 바와 같이, 소정의 브러시 객체들은 이들이 사용될 때 좌표 시스템과 어떻게 연관되는지에 대한 아이디어, 및 이들이 사용되는 형상의 경계 박스와 어떻게 연관되는지에 대한 아이디어를 갖는다. 이 크기는 브러시가 채우고 있는 객체에 기초한다.
브러시 기본 클래스는 변환, 일반 투명도 및 혼합 모드를 갖는다:
브러시(및 벡터 그래픽 및 MIL API 내의 다른 객체 자원들) 객체들은 변경가능 객체이며, 이들이 생성된 후에 기록 가능하고, 이들이 적격 사용된 후에 이들이 어떻게 행동하는지에 대해 일반 변경가능 패턴을 따른다.
브러시들(VisualBrush 및 DrawingBrush 제외)은 마크업에서의 사용을 위해 단순 신택스를 갖지만, 이러한 단순 신택스는 모든 속성 및 행동에 대한 액세스를 허용하지 않는다. 프로그래머가 단순 신택스가 제공하는 것보다 많은 액세스를 필요로 하는 경우, 프로그래머는 복합 신택스를 사용해야 한다. 복합 신택스는 다른 CLR 클래스들과 동일한 패턴을 따르므로 여기서는 중복을 피하기 위해 단순 신택스만이 설명된다.
다음은 현재의 구현에서 마크업을 위한 단순 신택스를 가진 브러시 타입들이 다:
많은 브러시 타입들은 이들의 파라미터들의 일부를 지정하기 위해 좌표 시스템을 사용한다. 이 좌표 시스템은 브러시가 사용되는 형상의 간단한 경계 박스에 대해 정의되거나, 절대적이고, 브러시가 사용될 때 활성화되는 좌표 공간에서 해석될 수 있다. 이들은 각각 RelativeToBoundingBox 모드 및 Absolute 모드로 알려져 있다.
SolidColorBrush는 솔리드 칼라로 평면을 채운다. 칼라의 알파 성분이 존재하는 경우, 이것은 브러시 내의 대응하는 불투명 속성과 곱셈 방식(multiplicative way)으로 조합된다.
이것은 간단한 타입이므로(즉, 속성들의 어느 것도 Changeable이 아님), 구현되어야 하는 유일한 보호 메소드는 CloneCore()이다. 또한, 이 객체를 무효로 만드는 값들의 어떠한 조합도 존재하지 않으므로, ValidateObjectState() 메소드를 제공할 필요가 없다. 이들 메소드는 다른 관련 메소드들은 첨부된 부록에 설명되어 있다.
다음은 SolidColorBrush의 마크업에 대한 단순 신택스이다:
브러시 클래스는 노출되는 SolidColorBrush 인스턴스들에 대한 정적 속성들을 포함한다. 각각은 동일 명칭의 칼라 값으로 설정된다. 이들은 표준 브러시이므로, IsChangeable을 거짓으로 설정한다(예를 들어 이 구현은 구축시 MakeUnchangeable()을 호출한다는 점에 유의하자.)
다음은 몇몇 표준 칼라를 설명한다:
Gradient들은 한 세트의 그래디언트 스톱들을 지정함으로써 드로잉된다. 이 그래디언트 스톱들은 소정의 수열에 따라 칼라를 지정한다. 현재 지원되는 2 종류의 그래디언트, 즉 리니어 그래디언트 및 방사 그래디언트가 존재한다. 그래디언트는 지정된 칼라 공간 내의 그래디언트 스톱들 사이에 보간을 행함으로써 드로잉된다.
그래디언트들은 그래디언트 스톱들의 리스트로 구성된다. 그래디언트 스톱들 각각은 칼라(포함된 알파 값을 가짐) 및 오프셋을 포함한다. 지정된 그래디언트 스톱이 없는 경우, 브러시는 (지정된 브러시가 없는 것처럼) 투명으로 드로잉된다. 하나의 그래디언트 스톱이 지정된 경우, 브러시는 지정된 하나의 칼라를 가진 솔리드 칼라로서 드로잉된다. 0 내지 1(0.0...1.0)의 범위의 오프셋을 가진 임의의 그래디언트 스톱들이 범위 (∞...0.0] 내의 가장 큰 스톱 및 범위 [1.0...+∞) 내의 가장 작은 스톱과 함께 고려된다. 고려되는 스톱들의 세트가 범위 0 내지 1 밖의 스톱을 포함하는 경우, 이 스톱에서 발생하는 보간 칼라를 나타내는 0(및/또 는 1)에서 암시적인 스톱(implicit stop)이 도출된다. 또한, 2개 이상의 스톱들이 동일 오프셋으로 설정되는 경우, 그 오프셋에서 (보간이 아니라) 하드 전이가 발생한다. 스톱들이 추가되는 순서는 이 오프셋에서의 행동을 결정하는데, 추가되는 최초 스톱은 그 오프셋 전의 유효 칼라이고, 설정되는 최종 오프셋은 이 스톱 후의 유효 칼라이며, 이 오프셋에서의 임의의 추가 스톱들은 무시된다.
이 클래스는 다른 자원 클래스들과 같은 Changeable이다:
SolidColorBrush와 같이, 이것은 애니메이션 컬렉션 내에 중첩된 Changeable들을 갖는다.
GradientSpreadMethod enum은 지정된 벡터 또는 공간의 외측에 어떻게 그래디언트가 드로잉되어야 하는지를 지정한다. 잔여 공간을 채우기 위해 엔드 칼라들 (end colors; 최초 및 최종)이 사용되는 Pad, 공간을 채우기 위해 스톱들이 역순으로 반복 재생되는 Reflect, 및 공간이 채워질 때까지 스톱들이 순서대로 반복되는 Repeat를 포함하는 3개의 가능한 값이 존재한다. 이 타입의 속성들에 대한 디폴트 값은 Pad이다:
도 24는 몇몇 GradientSpreadMethod 예를 (칼라가 아니라 계조(grayscale)로) 제공한다. 각각의 모양은 백색에서 회식으로 가는 리니어 그래디언트를 갖는다. 실선은 그래디언트 벡터를 나타낸다.
ColorInterpolationMode enum은 그래디언트 내의 칼라들에 대한 보간 모드를 정의한다. 2개의 옵션은 PhysicallyLinearGamma 및 PerceptuallyLinearGamma이다.
이것은 추상 기본 클래스이다.
LinearGradient는 벡터를 따르는 리니어 그래디언트 브러시를 지정한다. 개별 스톱들은 그 벡터를 따르는 칼라 스톱들을 지정한다.
다음은 LinearGradientBrush의 마크업에 대한 단순 신택스이다:
linear-gradient-brush:
"HorizontalGradient" comma-wsp color comma-wsp color|
"VerticalGradient" comma-wsp color comma-wsp color|
"LinearGradient" comma-wsp coordinate-pair comma-wsp color comma-wsp color
LinearGradient의 마크업은 오프셋 0 및 1에서의 2개의 칼라 스톱을 가진 LinearGradient의 지정을 허용한다. "LinaerGradient" 버전이 사용되는 경우, 시점 및 종점은 각각 지정된다. "HorizontalGradient" 버전이 사용되는 경우, 시점은 0,0으로 설정되고, 종점은 1,0으로 설정된다. "ViticalGradient" 버전이 사용되는 경우, 시점은 0,0으로 설정되고, 종점은 0,1로 설정된다. 이들 경우에, RelativeToBoundingBox인 디폴트 MappingMode가 사용된다.
RadialGradient는 프로그래밍 모델에서 리니어 그래디언트와 유사하다. 그러나, 리니어 그래디언트가 그래디언트 벡터를 정의하기 위한 시점 및 종점을 갖는 반면, 방사 그래디언트는 그래디언트 행동을 정의하도록 초점과 함께 원을 가진다. 원은 그래디언트의 종점을 정의하는데, 즉 1.0에서의 그래디언트 스톱은 원주의 칼라를 정의한다. 초점은 그래디언트의 중심을 정의한다. 0.0에서의 그래디언트 스톱은 초점의 칼라를 정의한다. 도 25는 (계조에서) 백색에서 회색으로 가는 RadialGradient를 나타낸다. 외측 원은 그래디언트 원을 나타내며, 점은 초점을 나타낸다. 이 그래디언트는 Pad로 설정된 SpreadMethod를 갖는다.
RadialGradient의 마크업은 각각 0 및 1의 오프셋의 2개의 칼라 스톱을 가진 RadialGradient의 지정을 허용한다. 디폴트 MappingMode가 사용되는데, 이는 디폴트 반경이 0.5인 RelativeToBoundingBox이다:
TileBrush는 타일을 설명하는 로직과, 타일이 영역을 채워야 하는 수단을 포함하는 추상 기본 클래스이다. TileBrush의 서브 클래스들은 콘텐츠를 포함하며, 무한 평면을 채우는 방법을 논리적으로 정의한다.
Stretch enum은 ViewBox(소스 좌표 공간)가 어떻게 ViewPort(목적 좌표 공간(destinatnion coordinate space)로 맵핑되는지를 설명하는 데 사용된다. 이것은 TileBrush에서 사용된다:
도 26은 스트레치의 예들을 제공한다. 이 예들에서, 콘텐츠는 상/좌(top/left) 정렬된다.
TileMode enum은 공간이 타일들에 의해 채워지는지, 그리고 어떻게 채워지는지를 설명하는 데 사용된다. TileBrush는 기본 타일이 어디에 있는지를 정의한다(ViewPort에 의해 지정됨). 공간의 나머지는 TileMode 값에 기초하여 채워진다.
도 27은 TileMode의 예들을 제공한다. 각 예의 최상좌(top left-most) 타일은 기본 타일이다. 이 예들은 None, Tile, FlipX, FlipY 및 FlipXY를 나타낸다.
VerticalAlignment enum은 콘텐츠가 어떻게 컨테이너 내에 수직으로 배치되는지를 설명하는 데 사용된다:
HorizontalAlignment enum은 콘텐츠가 어떻게 컨테이너 내에 수평으로 배치되는지를 설명하는 데 사용된다.
TileBrush 속성들은 타일(ViewBox)이 될 무한 평면의 사각 부분을 선택하고, 채워지고 있는 영역 내의 기본 타일이 될 목적 사각형(ViewPort)을 설명한다. 나머지 목적 영역은 나머지 공간을 채우기 위해 원본 타일이 복제되는지, 그리고 어떻게 복제되는지를 제어하는 TileMode 속성에 기초하여 채워진다.
TileBrush의 콘텐츠는 고유 경계를 갖지 않으며, 무한 평면을 효과적으로 설명한다. 이들 콘텐츠는 그들 자신의 좌표 공간에 존재하며, TileBrush에 의해 채 워지고 있는 공간은 적용시의 로컬 좌표 공간이다. 콘텐츠 공간은 ViewBox, ViewPort, Alignments 및 Stretch 속성들에 기초하여 로컬 공간으로 맵핑된다. ViewBox는 콘텐츠 공간 내에 지정되며, 이 사각형은 ViewPort 사각형으로 맵핑된다.
ViewPort는 콘텐츠가 최종적으로 드로잉되어 이 브러시에 대한 기본 타일을 생성하는 위치를 정의한다. ViewPortUnits의 값이 Absolute인 경우, ViewPort의 값은 적용시의 로컬 공간에 있는 것으로 간주된다. 그 대신, ViewPortUnits의 값이 RelativeToBoundingBox인 경우에는, ViewPort의 값은, 페인팅되고 있는 객체의 경계 박스의 상/좌 코너가 0,0이고 동일 박스의 하/우 코너가 1,1인 좌표 공간 내에 있는 것으로 간주된다. 예를 들어, 100,100에서 200,200으로 드로잉되어 채워지고 있는 RectangleGeometry를 고려하자. 그러면, ViewPortUnits가 Absolute인 경우, (100,100,100,100)의 ViewPort는 전체 콘텐츠 영역을 설명한다. ViewPortUnits가 RelativeToBoundingBox인 경우, (0,0,1,1)의 ViewPort는 전체 콘텐츠 영역을 설명한다. ViewPort의 크기가 공백이고, 스트레치가 None이 아닌 경우, 이 브러시는 아무 것도 렌더링 하지 않는다.
ViewBox는 콘텐츠 공간에 지정된다. 이 사각형은 정렬 속성 및 스트레치 속성에 의해 결정되는 바와 같이 ViewPort 내에 맞도록 변환된다. 스트레치가 None인 경우, 콘텐츠에는 어떠한 스케일링도 적용되지 않는다. 스트레치가 Fill인 경우, ViewBox는 ViewPort와 동일한 크기가 되도록 X 및 Y에서 독립적으로 스케일링된다. 스트레치가 Uniform 또는 UniformToFill인 경우, 로직은 유사하지만, X 및 Y 치수들이 균일하게 스케일링되어 콘텐츠의 종횡비가 유지된다. 스트레치가 Uniform인 경우, ViewBox는 ViewPort의 크기와 같은, 보다 많이 제한된 치수를 갖도록 스케일링된다. 스트레치가 UniformToFill인 경우, ViewBox는 ViewPort의 크기와 동일한 보다 적게 제한된 치수를 갖도록 스케일링된다. 이것을 고려하는 또 하나의 방법은, Uniform 및 UniformToFill 양자가 종횡비를 유지하지만, Uniform은 전체 ViewBox가 ViewPort 내에 있는 것을 보장하고(잠재적으로 ViewBox에 의해 커버되지 않는 ViewPort의 부분을 남김), UniformToFill은 전체 ViewPort가 ViewBox에 의해 채워지는 것을 보장하는(잠재적으로 ViewBox의 부분들이 ViewPort 외측에 있게 함) 것이다. ViewBox의 영역이 공백인 경우, 어떠한 스트레치도 적용되지 않는다. 정렬은 여전히 발생하여, "포인트" ViewBox를 배치한다.
ViewPort가 결정되고(ViewPortUnits에 기초하여), ViewBox의 목적 크기가 결정되면(스트레치에 기초하여), ViewBox는 ViewPort 내에 배치되어야 한다. ViewBox가 ViewPort와 동일한 크기인 경우(스트레치가 Fill이거나, 이것이 단지 다른 3개의 스트레치 값 중 하나를 가지고 발생하는 경우), ViewBox는 ViewPort와 동일하도록 원점에 배치된다. 그렇지 않은 경우, HorizontalAlignment 및 VerticalAlignment가 고려된다. 이들 속성에 기초하여, ViewBox는 X 및 Y 치수에서 정렬된다. HorizontalAlignment가 Left인 경우, ViewBox의 좌측 에지(edge)는 ViewPort의 좌측 에지에 배치된다. 이것이 Center인 경우, ViewBox의 중심은 ViewPort의 중심에 배치되고, Right인 경우, 우측 에지들이 만나게 된다. 이 프로세스는 Y 차원에 대해 반복된다.
ViewBox가 공백인 경우, 이것은 설정되지 않은 것으로 간주된다. ViewBox가 설정되지 않으면, ContentUints가 고려된다. ContentUnits가 Absolute인 경우, 어떠한 스케일링 또는 오프셋도 발생하지 않으며, 콘텐츠는 변환 없이 ViewPort 내에 드로잉된다. ContentUnits가 RelativeToBoundingBox인 경우, 콘텐츠 원점은 ViewPort 원점에 정렬되고, 콘텐츠는 객체의 경계 박스의 폭 및 높이에 의해 스케일링된다.
TileBrush로 공간을 채울 때, 콘텐츠는 위와 같이 ViewPort 내로 맵핑되고, ViewPort로 클립된다. 이것은 채움을 위한 기본 타일을 형성하며, 공간의 나머지는 브러시의 TileMode에 기초하여 채워진다. 설정된 경우, 브러시의 변환이 적용되는데, 이는 다른 맵핑, 스케일링, 오프셋팅 등 이후에 발생한다.
VisualBrush는 Visual에 의해 지정된 콘텐츠를 가진 TileBrush이다. 이 브러시는 복합 패턴을 생성하거나 장면의 다른 부분들의 콘텐츠들의 추가적인 사본들을 드로잉하는 데 사용될 수 있다.
전술한 바와 같이, VisualBrush는 복합 신택스를 통해 설명될 수 있지만 마 크업을 위한 단순 신택스를 갖지 않는다.
DrawingBrush는 Drawing에 의해 지정된 콘텐츠를 가진 TileBrush이다. 이 브러시는 DrawingContext를 통해 생성된 복합 패턴을 생성하는 데 사용될 수 있다.
전술한 바와 같이, DrawingBrush는 복합 신택스를 통해 설명될 수 있지만 마크업을 위한 단순 신택스를 갖지 않는다.
ImageBrush는 ImageSource에 의해 지정된 콘텐츠를 가진 TileBrush이다. 이 브러시는 이미지로 공간을 채우는 데 사용될 수 있다.
다음은 ImageBrush의 마크업에 대한 단순 신택스이다:
image-brush:
"Image" image-uri
VideoBrush는 VideoData에 의해 지정된 콘텐츠를 가진 TileBrush이다. 이 브러시는 비디오로 공간을 채우는 데 사용될 수 있다.
다음은 VideoBrush의 마크업에 대한 단순 신택스이다:
video-brush:
"Video"video-uri
NineGridBrush는 항상 그의 콘텐츠 이미지로 객체 경계 박스를 채우는 브러시이며, 이미지 스트레치는 순전히 비주얼 스케일을 통해 달성되지는 않는다. 이미지 소스는 4개의 경계에 의해 9개의 사각형으로 분할된다(따라서 그 명칭이 NineGrid이다). 9개의 영역 각각 내의 이미지의 콘텐츠들은 이들이 객체 경계 박스를 채울 때까지 0, 1 또는 2의 치수로 스케일링된다. 각각의 섹션이 스케일링되는 치수는 이 도면에서 볼 수 있는데, 도 28은 Top, Left, Bottom 및 Right 경계들 에 의해 정의되는 9개의 그리드를 나타내는 NineGrid의 개념을 나타낸다. 각 그리드 스퀘어 내의 화살표들은 콘텐츠들이 ViewPort 크기를 만족시키도록 스트레치될 치수를 나타낸다.
위에 도시된 9개의 그리드 영역 외에, 선택적인 "제10(tenth)" 그리드가 존재한다. 이것은 ViewPort에 중심을 갖고 스케일링되지 않은 추가 이미지의 형태를 취한다. 이것은 버튼의 중앙에 모양을 배치하는 등등에 사용될 수 있다. "제10 그리드"는 그림문자로 지칭되며, GlyphImageSource 속성에 의해 노출된다:
경계 멤버들은 이미지 픽셀들 내의 이미지의 에지로부터 카운트된다는 점에 유의한다.
다음은 NineGridBrush의 마크업에 대한 간단한 신택스이다:
nine-grid-brush:
"NineGrid" image-uri int int int int [glyph-image-uri]
4개의 정수는 각각 LeftBorder, RightBorder, TopBorder 및 BottomBorder에 대한 값이다. 제10 그리드 또는 그림문자에 대한 최종 URI는 선택적이다.
Pen은 브러시, 및 공간/형상을 어떻게 스트로크할 것인지를 설명하는 다른 파라미터들을 취하는 객체이다. 개념적으로, 펜은 형상으로부터 스트로크 영역을 어떻게 생성할 것인지를 설명한다. 형상의 에지들, 펜의 두께, PenLineJoin, PenLineCap 등에 기초하여 새로운 영역이 생성된다. 이러한 영역이 생성되면, 브러시로 채워진다.
PenLineCap는 스트로크된 선의 단부들(ends)이 어떻게 드로잉되는지를 결정한다.
PenDashCap는 대쉬(dash) 스트로크 선 내의 각각의 대쉬의 단부들이 어떻게 드로잉되는지를 결정한다:
PenLineJoin은 선을 스트로크할 때 어떻게 조인트들이 드로잉되는지를 결정한다:
DashArrays 클래스는 공통의 공지 대쉬 스타일들에 대한 액세스를 제공하는 정적 속성들을 포함한다:
칼라
칼라 아키텍처는 Color가 컨택스트를 요구하는 것을 포함하는 몇몇 일반 원 리 상에서 구축되며, 따라서 칼라 값들은 작업 흐름에서 칼라 불일치를 최소화하기 위해 명시적으로 지정된 컨텍스트 또는 암시적으로 가정된 디폴트를 갖는다. 또한, 코어 플랫폼 설계는 보안성, 신뢰성, 유지성, 미래 확장성 및 성능을 위해 긴 수명과 함께 최소의 코드 경로 및 API를 요구하며, 따라서 렌더링 코어는 착신 콘텐츠 스트림(incoming content stream)이 변환되고 발신 스트림(outgoing stream)이 변환되는 scRGB 코드 경로(보다 낮은 품질을 가진 추가 sRGB 레거시 경로도 허용됨)로 주로 제한될 수 있다. "scRGB"는 IEC 61966-2-2 국제 표준에 근거한 내부 벡터 그래픽 디폴트 표현을 지칭한다("sc"가 의미하는 것에 대한 공식 정의는 제공되지 않았지만, "표준 합성"은 본 명세서에서 이것이 합성 처리를 위한 최적 공간임을 명확히 하도록 돕는 데 사용된다).
성능은 복합 처리가 실시간 렌더링 단계(stage)에서가 아니라 가능한 한 칼라 객체 정의/사양 단계에 가깝게 수행될 것을 요구하며, 이것은 API에 대한 칼라 파라미터들이 사양 상에서 (본질적으로 즉시) scRGB로 변환되고, scRGB 칼라 값들이 비-scRGB 정의 객체들에 대해 유지되고 동기화될 것을 요구한다. 사용의 용이성은, 가장 일반적인 개발자 사례들이 먼저 노출되나 가장 진보된 사례가 명백하지만 최소인 API를 갖는, 계층화된 API를 요구하며, 따라서 sRGB API들이 제공되고(그러나 내부적으로 scRGB로 즉시 변환됨), scRGB API들이 제공되며, 최소 컨텍스트 관련 API(minimal context associated API)가 진보된 CMYK(시안-마젠타-옐로우-블랙), 단색, 휴먼 비주얼 시스템 및 멀티채널 솔루션을 지원하도록 제공된다. scRGB는 본질적으로 "무한한" 칼라 전 영역(color gamut)이므로, 실세계 장치들로 scRGB 작업 흐름을 "후크"하기 위해 추가적인 장치 특성화 및 전 영역 맵핑 솔루션들이 필요하다.
칼라는 외적인 물리적 지각에 의해 가장 자주 일반적으로 발생하는 정신적 인식이다. 이는, 인식된 칼라들을, 장치들을 통해, 그리고 사용자들 사이에 효과적으로 전송하기 위해 컴퓨터 기반 칼라가 물리적 컨텍스트를 필요로 한다는 것을 의미한다. 역사적으로, 다양한 기술들은, 칼라 아키텍처 구현들에 대한 합리적인 컨텍스트적 의미를 제공하는 데 있어 일관되지 않았는데, 예를 들면 이것은 "적색"이 하나의 장치에서는 "오렌지"를, 다른 장치에서는 "핑크"를 의미하는 결과를 낳았으며, 이러한 불일치를 해결할 방법이 거의 없었다.
현재의 아키텍처는 임의의 칼라 객체에 대한 암시적(디폴트 사용) 및 명시적 칼라 컨텍스트의 조합을 제공한다. 이것은 컨텍스트적 의미 없는 어떠한 칼라 객체도 존재하지 않는다는 것을 의미한다. 이것은 불완전한 기술이며, 따라서 아키텍처의 일 국면은 기술이 진보함에 따라 진화할 수 있는 방식으로 일관된 칼라 컨텍스트를 제공하기 위한 것이다. 대부분의 컴퓨터 사용자들(및 대부분의 개발자들)은 칼라 관리를 행하기를 원치 않으며, 단순히 칼라가 정확하게 구현되는 것을 선호한다는 점에 유의하자.
일반적으로, 아키텍처는 내부 코드 경로들을 최소화하려고 시도하는데, 이는 하나는 품질 및 미래의 하드웨어에 대한 것이고, 다른 하나는 레거시 및 메모리/성능 제한에 대한 것인 2개의 기본 코드 경로를 내부적으로 가능하게 함으로써 어느 정도 달성된다. MIL 코어 내부 렌더링 및 합성 엔진은, (64bpp scRGB도 고려중이 고, 64bpp 지원의 몇몇 인스턴스는 고정 소수점으로, 몇몇은 부동 소수점으로, 몇몇은 정수로 가장 잘 구현되지만) 32bpp sRGB 및 128bpp 부동 소수점(floating point) scRGB를 지원한다.
아키텍처는 캡쳐에서, 표시로, 편집으로, 저장으로, 인쇄로의 128bpp scRGB 경로를 제공하며(표시는 128bpp 백 버퍼 및 10bpc 이상의 프론트 버퍼임), 성능, 메모리 및/또는 대역폭의 품질을 희생시키는 레거시 32bpp sRGB 경로를 허용한다.
본 발명의 칼라 관리는 추가적인 유연성을 가진 장치 및 애플리케이션을 제공함으로써 이전의 단점을 개선하며, 프로파일 기반 칼라 관리 솔루션을 제공한다. 가장 일반적인 시나리오는 공통 UI 요소들에 대한 칼라 값들의 취득 및 설정을 지원하는 scRGB 및 sRGB 칼라 객체들에 기초하며, 웹, 멀티미디어 및 컴퓨터 그래픽에 대한 대부분의 콘텐츠 생성을 지원한다. 덜 일반적인 시나리오는 직업적인 사진 작업 흐름에 대한 특정 작업 공간 프로파일을 가진 RGB 칼라 컨텍스트를 이용하는 것, 정의되지 않은 미래의 작업 흐름을 지원하는 유연성을 제공하는 것은 물론 니치 프린팅(niche printing) 및 프레스 시나리오를 지원하는 프리프레스(prepress) 및 그래픽 설계 작업, 및 단색 및 멀티채널 칼라 작업 흐름을 위한 칼라 객체를 편집하기 위해 CMYK 칼라 값들을 사용하는 것을 포함한다. HVSV(인간 비주얼 시스템 기반 공간) 작업 흐름은 몇몇 니치 전문 사진 편집 시나리오(niche professional photography editing scenario)를 지원한다.
품질 및 비트 깊이 면에서 계속 진보하는 캡쳐 센서 기술에 대응하기 위하여, 이미징은 현재의 디지탈 네가티브 이니셔티브(digital negative initiative)를 지원하기 위하여 모든 특징/API에 대해 적어도 64bpp 포맷을 지원한다. 본 발명이 벡터 그래픽에 대한 새로운 아키텍처를 구현함에 따라 벡터 그래픽은 채널 비트당 32비트 부동 소수점의 정확도로 구현될 것이다. 이 구현은 계조 및 HSV 인터페이스는 물론 통상적인 8bpc 칼라 액세스를 제공하기 위해 실제로는 "은닉(hidden)"된다.
또 하나의 칼라 데이터 타입은 "CornflowerBlue" 또는 "Pantone" 칼라들과 같은 칼라 데이터로 명명된다. 통상적인 칼라 관리 프로파일을 확장하는 것에 기초하는 칼라 컨텍스트를 제공함으로써, 매우 일반적이고 강력한 칼라 명명 인터페이스가 제공된다. 이전의 API 및 일반 관례와의 소정의 레거시 호환성을 유지하기 위하여, 디폴트 구축자들은 sRGB 입력을 향해 바이어스된다.
벡터 그래픽에 대한 칼라 공간 지원은 네이티브 scRGB 지원, 명시적 칼라 컨텍스트를 요구하지 않는 sRGB 및 유사 공간들에 대한 속성 지원, 명시적으로 관련된 칼라 컨텍스트를 또한 요구하지 않는 HSV(색조, 채도 및 명암)와 같은 sRGb 또는 scRGB와 밀접하게 관련된 칼라 공간들, 팔레트와 같은 명명된 칼라들 및 관련 칼라 공간들 및 암시적 또는 명시적으로 관련된 칼라 컨텍스트에 기초하는 인덱스된 칼라 공간들, 및 CMYK, 하이파이 칼라(CMYK 더하기 오렌지 및 녹색), CcMmYK 잉크젯 칼라 공간들과 같은 명시적으로 관련된 칼라 컨텍스트들은 물론 추가적인 칼라 채널들을 요구하는 칼라 공간들에 대한 메소드 지원, 및 미래의 잠재 스펙트럼 칼라 지원으로 분할된다.
이러한 칼라 공간들은 MIL 코어 또는 합성 엔진에서의 렌더링을 위해 scRGB 또는 sRGB로 변환되지만, 이들은 저장되거나, 벡터 그래픽 마크업 언어를 프로그램 설계 언어로 사용하여 (CMYK와 같은) 프린터로 전송될 수 있다. 칼라 마크업 신택스는 16진수(hexadecimal), 공지의 칼라, sRGB 속성, 및 진보된 칼라 컨텍스트의 4가지 기본 사양 메커니즘을 포함한다. 처음의 3개는 sRGB 칼라 공간 칼라 컨텍스트를 취한다.
아래의 예는 이들 4개의 메커니즘을 이용하여 그래디언트를 생성한다:
제1 백그라운드 칼라는 16진수(#ee7711)로 지정된다. 이 16진수 표현은 .NET 프레임워크 V1 및 WinForms가 어떻게 칼라들을 지정했는지와 동일하다. 이것은 4개의 상이한 변화, 즉 #RGB, #ARGB, #RRGBBB 또는 #AARRGGBB를 허용하도록 유연하다.
제2 백그라운드 칼라는 공지된 칼라(CornFlowerBlue)로 지정된다. 이 표현은 .NET 프레임워크 V1 및 WinForms가 어떻게 칼라들을 지정했는지와 동일하다. 이것은 명명된 칼라 값들에 기초한다. 명명된 칼라 솔루션들은 Pantone, Trumatch 및 다른 명명된 칼라들이 칼라 컨텍스트들에 의해 지원되는 것을 가능하게 한다. 이것은 또한 알파 채널 설정을 지원한다.
제1 그래디언트 스톱은 칼라 컨텍스트("sGray.icc 0.5")를 이용하여 지정된다. 텍스트 스트링은 칼라 컨텍스트 파일명을 지정하는데, 이는 URL 또는 URI일 수 있다. 이 샘플은 인쇄 렌더링 시간에 RGB 값들이 먼저 단색 값들로 변환될 필요 없는 단색 인쇄를 명백히 지원함을 설명하기 위한 것이다.
제2 그래디언트 스톱은 sRGB 속성들(A="0.8" R="0.2" G="1" B="0.2")을 이용하여 지정된다. 이 표현은 .NET 프레임워크 V1 및 WinForms가 어떻게 칼라들을 지정했는지와 동일하다.
제3 그래디언트 스톱은 칼라 컨텍스트(="mswopintent8.icm 0.9 0.2 0.1 0.3")을 이용하여 지정된다. 텍스트 스트링은 칼라 컨텍스트 파일명을 지정하는데, 이는 URL 또는 URI일 수 있으며, 알파 채널 설정을 지원할 수 있다. 이 샘플은 Publisher 및 다른 그러한 애플리케이션들에 대해 요구되는 바와 같은 CMYK 지 원을 나타낸다.
함께 취해질 때, 이 샘플들은 칼라 요구를 지원하는 매우 강력하고 명확한 신택스를 제공한다. 칼라 컨텍스트는 전역적으로 지정될 수 있으며, 내부 칼라 참조들은 예를 들어 성능 최적화를 위해 이 전역 컨텍스트를 따르도록 요구될 수 있다는 점에 유의한다.
전술한 바와 같이, 칼라 객체들이 벡터 기반인지 래스터(raster) 기반인지에 관계없이 칼라 객체들에 대해 칼라 컨텍스트가 요구된다. 성긴 레벨(coarse level)에서, 칼라 컨텍스트는 프로파일로서 간주될 수 있으며, 칼라 객체의 칼라 공간과 휴먼 비주얼 시스템 사이의 관계를 제공한다. 칼라 컨텍스트는 사용자 칼라 공간과 scRGB 칼라 공간(또는 휴먼 비주얼 시스템 칼라) 사이의 관계에 관한 정보를 제공한다. 이것은 CMYK 및 이전에 효과적인 방식으로 가능하지 않았던 다른 칼라 정보를 "라운드 트립핑(round-tripping)"하는 것을 허용한다.
오늘날 실제로는, sRGB, scRGB, AdobeRGB, BruceRGB, AppleRGB, TomRGB, CorbisRGB, JoeRGB, HSV, HSB, XYZ, LAB, LUV, YUV, YCC, CMYK, CcMmYK, CMYKOG, 명도 그레이스케일, 휘도 그레이스케일 등과 같은 수백개의 상이한 칼라 공간들이 존재한다. 많은 개별 칼라 공간들은 감마, 원색(primary), 백색점 및 비트 정밀도(bit precision)를 포함하는 시맨틱의 정의와 함께 레드, 그린 및 블루의 시각적 인식에 대한 근사치를 포함하는 3개의 채널에 의해 주로 정의되는 RGB 공간들과 같은 칼라 공간들의 클래스들로 분류될 수 있다. 비트 정밀도는, 보다 낮은 비트 정밀도(예를 들어 채널당 8 비트)가 통상 합리적인 인코딩 효율을 달성하기 위해 광범위한 비선형 보상을 요구하므로 필요하게 된다.
칼라 컨텍스트 클래스의 제공은 가능한 칼라 공간 클래스들의 세트를, 그레이스케일, RGB, HSV, CMYK, LAB, LCH, CcMmYK, CMYKOG, 스펙트럼 칼라들 및 예술적 효과를 위해 사용되는 이중 톤, 삼중 톤 및 사중 톤 공간들과 같은 특수 효과 공간들과 같은 훨씬 적은 세트로 줄인다. 동일한 기본 의미(underlying meaning)를 공유하지만 상이한 좌표 시스템을 제공하는(직선(rectilinear) 및 극(polar) 형상들과 유사) 공간들을 조합함으로써 추가적인 감소가 가능하다. 이것은 HSV를 RGB 칼라 공간 클래스의 최상위 메소드로, LCH를 LAB 칼라 공간 클래스의 최상위 메소드로 만든다.
특수 효과 칼라 공간들을 스펙트럼 칼라와 조합하고, CcMmYK 및 CMYKOG에 대한 지원을 포함하고, 단지 이 컨텍스트 내의 칼라 값을 동적 어레이가 되게 하는 것도 가능한데, 이는 진보된 사용자들만이 이 기능을 사용하기 때문이다. 칼라 공간들을 scRGB로 줄이기 위한 추가적인 감소가 가능한데, 이는 sRGB 및 다른 RGB 공간들, 및 칼라 컨텍스트를 가진 멀티 채널 칼라 공간을 지원한다. 이것은 scRGB 및 멀티 채널 공간들만을 포함하는 합리적인 수의 지원할 기본 칼라 공간 클래스를 남긴다.
ColorContext는 벡터 그래픽 Color 클래스 또는 ImageData 객체와 연관된다. 또 하나의 대안은 비주얼들을 단일 ColorContext로 제한하는 것이다. 이것은 많은 환경에서 칼라 변환 및 검증의 양을 최적화하는 것을 도우며, 애플리케이션 개발자들에게 보다 자연스러울 수 있는데, 예를 들어 개별 제어가 다수의 칼라 시스템으 로부터의 칼라들을 사용하지 않을 수 있다. 칼라 프로파일은 동적 변경을 허용하는 메커니즘을 통해 다수의 칼라 타입을 명시적으로 사용하는 진보된 애플리케이션에 대해 변경되는 것이 여전히 허용된다는 점에 유의한다. ColorContext는 또한 2개의 장치 색역(color gamut)들 사이의 렌더링 의도(rendering intent) 또는 색역 맵핑(color gamut mapping)이 지정되고, 따라서 칼라 객체와 연관되는 것을 허용한다. ColorContext는 단일 칼라 객체만을 다루므로, 목적 색역은 가상 장치일 수 있다. 이것은 ColorContext가 칼라 공간의 객체 설명은 물론 칼라에 대한 주체 렌더링 의도를 포함하는 것을 허용한다.
칼라 명칭들은 칼라 컨텍스트와 연관된 프로파일 내에 삽입된 간단한 룩업 테이블들인데, 이들은 ColorContext의 타입에 기초한 칼라 값과 실제 칼라 명칭 사이의 링크를 제공한다. 이것은 각 칼라 객체에 대한 상이한 칼라 명명 사전을 허용한다. 예를 들어, 프로세스 칼라 객체들을 가진 Trumatch와 같은 한 타입의 명명 시스템과 스폿 칼라 객체들을 가진 Pantone과 같은 다른 타입의 명명 시스템을 연관시키는 것이 가능하다.
공개 벡터 그래픽 Color 타입은 보다 낮은 레벨의 시스템에 매칭하여, 이 보다 낮은 레벨의 시스템에 데이터를 전송할 때 변환을 최소화함으로써 성능을 최적화한다. 부동 소수점 값들의 개별 "네이티브"(즉 CMYK 등) 세트는 칼라 컨텍스트에 저장되며, 임의의 변경이 발생할 때 동기화된다. 네이티브 ColorContext colorValue는 그레이스케일, RGB 및 심지어 CMYK 칼라 공간들을 투명하게 지원하기 위해 부동 소수점들의 어레이에 기초하는 값 타입(구조)이다. 네이티브 ColorContext ColorValue 어레이는 동적이어야 하며, 1, 3, 4 또는 8 칼라 채널로도 제한되지 않는다. 이것은 이 동일한 아키텍처를 가진 스펙트럼 또는 단축 스펙트럼(abridged spectral) 칼라 프로세스 솔루션들을 허용한다. 종종 부분적으로만 사용되는 5 요소 어레이의 비용에 비해 할당의 비용이 매우 크지만, 이것은 미래를 위한 일관되고 조리있고 유연한 솔루션을 보장하며, scRGB 작업 흐름이 사용될 때 비용이 없는 경우는 없다는 점에 유의할 것이다. 알파 값은 ColorContext ColorValue로부터 분리되는데, 이것은 상이한 개념이고 대부분의 사용에 있어서 다르게 취급되기 때문이다.
| 명칭 | 타입 | 설명 | 다른 정보 |
| InternalColor | Float Red, Float Green, Float Blue, Float Alpha | 성능을 최적화하기 위하여 내부 렌더링 칼라 구조와 동일한 구조 | 내부 구조, 이 제2 내부 구조는 데이터의 효율적인 마샬링(marshaling)을 지원하는 데 사용된다. |
| context | ColorContext | 칼라 컨텍스트 정보를 사용하는 것과 관련된 메소드를 제공하는 칼라 컨텍스트 | InternalColor 값들에 동기화되는 네이티브 칼라 값들을 갖는다. |
| 명칭 | 독립변수 (Argument) | 설명 | 다른 정보 |
| FromProfile(...) | String | ICC 또는 다른 프로파일 파일명 기반 구축자(profile filename-based constructor) | 공개 정적 (Public static) |
| FromProfileAndRenderingIntent(...) | String, String | ICC 또는 다른 프로파일 파일명 기반 구축자 | 공개 정적 |
| FromAValues(...) | Float, float[], filename | 알파 채널 값, 부동 소수점 값들의 어레이 및 ICC 또는 다른 프로파일 파일명에 기초한 일반 구축자 | 공개 정적 |
| FromValues(...) | Float[], filename | FromAValues(...)와 동일하지만, 알파는 1.0f인 것으로 가정된다. | 공개 정적 |
| FromARGB(...) | byte, byte, byte, byte | 알파, 레드, 그린 및 블루 sRGB 값들에 기초한 레거시 sRGB 구축자 | 공개 정적, sRGB 값들은 처리를 위해 scRGB로 내부 변환된다. |
| FromRGB(...) | byte, byte, byte | 레드, 그린 및 블루 sRGB 값들에 기초한 레거시 sRGB 구축자(알파는 1.0f인 것으로 가정됨) | 공개 정적, sRGB 값들은 처리를 위해 scRGB로 내부 변환된다. |
| FromScRGB(...) | Float, float, float, float | 알파, 레드, 그린 및 블루 scRGB 값들에 기초한 scRGB 구축자 | 공개 정적 |
시스템 칼라 UI 객체들의 칼라 값의 취득은 다른 많은 진보된 타입의 씨밍(theming)과 같이 다른 컨텍스트에 종속할 수 있으며, 애플리케이션 모델/씨밍 API를 통해 다른 시스템 메트릭들과 함께 수집되어야 한다는 점에 유의한다.
| 명칭 | 리턴 타입 | 설명 | 다른 정보 |
| R | byte | 현재 칼라의 레드 scRGB 성분의 레드 sRGB 값 | R/W |
| G | byte | 현재 칼라의 레드 scRGB 성분의 그린 sRGB 값 | R/W |
| B | byte | 현재 칼라의 레드 scRGB 성분의 블루 sRGB 값 | R/W |
| A | byte | 현재 칼라의 레드 scRGB 성분의 알파 sRGB 값 | R/W |
| ScR | float | 현재 칼라의 레드 scRGB 성분의 레드 scRGB 값 | R/W |
| ScG | float | 현재 칼라의 레드 scRGB 성분의 그린 scRGB 값 | R/W |
| ScB | float | 현재 칼라의 레드 scRGB 성분의 블루 scRGB 값 | R/W |
| ScA | float | 현재 칼라의 레드 scRGB 성분의 알파 scRGB 값 | R/W |
scRGB 값들은 확장된 동적 범위 및 색역을 지원하기 위하여 0.0 이하 및 1.0 이상의 범위일 수 있다.
칼라 객체들에 대한 오퍼레이터 오버라이드(override)는 컨텍스트에 특유할 수 있는데, 이는 칼라들의 혼합 및 추가가 칼라 공간에 종속하기 때문이다. 예를 들어, 휘도 RGB 공간들은 가산적(additive)이고 선형적이어서, 일반적인 수학 연산들이 상당히 직관적(intuitive))이지만, 명도 RGB 공간들은 물론 CMYK 공간들은 선형적이지도 가산적이지도 않으므로, 이러한 연산들은 상이한 비주얼 효과를 산출한다. 또한, 대부분의 칼라 연산들은 원하는 색역을 초과하는 값을 유발할 수 있으며, 따라서 색역 맵핑 보상을 필요로 한다. 이것은 저품질 클램핑 만큼 간단하거나 훨씬 더 복잡할 수 있다.
몇몇 애니메이션 오퍼레이터 오버로드들은 이들이 scRGB ColorContext로 특정하여 제한되는 경우에 제공될 수 있는데, 이는 scRGB가 물리적 광에 기초하고 선형적으로 가산적으로 혼합되기 때문이다. CMYK, sRGB 및 기타 칼라 공간들은 매우 상이한 혼합 모델들을 갖는다.
| 명칭 | 리턴 타입 | 독립변수 | 설명 | 다른 정보 |
| + | Color | Color, Color | 컨텍스트 종속 칼라 가산 | RGB 컨텍스트는 scRGB 및 컴퓨터 그래픽에 올바른 선형 wrt 휘도(광자들이 어떻게 혼합되는지)이다. |
| Add | Color | Color, Color | 컨텍스트 종속 칼라 가산 | 공개 |
| - | Color | Color, Color | 컨텍스트 종속 칼라 감산 | 공개 |
| Subtract | Color | Color, Color | 컨텍스트 종속 칼라 감산 | 공개 |
| * | Color | Color, float | 컨텍스트 종속 칼라는 칼라에 부동 소수점 값을 곱한다. | 공개 |
| Multiply | Color | Color, float | 컨텍스트 종속 칼라는 칼라에 부동 소수점 값을 곱한다. | 공개 |
| Equals | Bool | Color, Color | 2개의 칼라 값이 동일한 경우 참을 리턴한다. | 공개 |
| Equals | Bool | Object | 칼라 객체가 현재의 칼라와 같은 경우 참을 리턴한다. | 공개 |
| == | Bool | Color, Color | 2개의 칼라 값이 동일한 경우 참을 리턴한다. | 공개 |
| IsEqual | Bool | Color, Color | 2개의 칼라 값이 동일한 경우 참을 리턴한다. | 공개 |
| != | Bool | Color, Color | 2개의 칼라 값이 동일하지 않은 경우 참을 리턴한다. | 공개 |
| IsNotEqual | Bool | Color, Color | 2개의 칼라 값이 동일하지 않은 경우 참을 리턴한다. | 공개 |
멀티채널 칼라들에서 사용되는 것과 유사한 메소드들도 HSB, YCC 및 YUV 및 sRGB 또는 scRGB와 밀접하게 관련된 유사한 칼라 공간들을 지원하는 데 사용될 수 있다.
| 명칭 | 리턴 타입 | 독립변수 | 설명 | 다른 정보 |
| Clamp | Color | Void | 범위 [0.0...1.0] 내의 칼라 값들을 클램프한다. | 공개 |
| GetHashCode | int | Void | 칼라 해쉬 코드를 리턴한다. | 공개 |
| Name | String | 칼라명을 리턴한다. | colorcontext 호출과 중복됨 | |
| ToRgbColor | None | Color | 현재 칼라의 scRGB 등가 칼라를 리턴한다. | 공개 |
| ToString | String | Void | 칼라의 포맷된 스트링 값을 리턴한다. | 공개 |
| AreClose | Bool | Color, Color | FloatUtil 함수를 이용하여 칼라 값들이 가까운 경우 참을 리턴한다. | 정적 |
| IsClose | Bool | Color | FloatUtil 함수를 이용하여 칼라가 현재 칼라에 가까운 경우 참을 리턴한다. | 공개 |
| SetRenderingIntent | Bool | String | ColorContent에 대한 렌더링 의도가 성공적인 경우 참을 리턴한다. | 공개 |
sRGB에 기초한 rgb 및 argb 형태에서의 부동 값들은 0.0 내지 1.0의 스케일 상에서 지정된다. 정의에 의하면, 이 값들은 이 범위를 결코 벗어나지 않으며, 따라서 클램프되어야 한다. 역으로, scRGB 기반 값들은 0.0 이하, 1.0 이상에서 유효하다. 이 값들은 목적 장치가 확장 색역을 지원할 수 없는 경우에만 클립되어야 한다. 이것은 목적 색역과 관련된 프로파일에 질의함으로써 결정될 수 있다. 이상적으로는, 표시를 위해 그래픽 하드웨어는 DX의 색역 관리 기능을 이용하여 이러한 문제를 해결할 수 있다.
분해되고 있는 스트링이 무효인 경우, 칼라는 ARGB=(0.0,0.0,0.0,0.0)으로 초기화된다.
계속할 때, 이 값은 칼라가 공지 칼라로서 생성되었을 경우 공지 칼라명으로 기록된다. 그렇지 않은 경우, rgb(float, float, float) 형태는 알파가 1.0인 경 우에 사용된다. 알파가 1.0이 아닌 경우, argb(float, float, float, float) 형태가 사용된다.
래스터 그래픽 또는 이미징 또는 픽셀 포맷들은 위의 벡터 그래픽 솔루션들과 다르다. 간단하게 말하면, 이미징 입력은 검정에서 백색, sRGB, scRGB, CMYK까지의 다양한 지원 칼라 공간들을 가진 1 bpp에서 128 bpp까지의 거의 모든 것일 수 있다. 따라서, ImageData에 대한 칼라 솔루션은 ImageData 또는 픽셀 포맷들에 대한 ColorContext를 필요로 한다. 이것은 표준 파일 포맷들 내의 내장 프로파일(embedded profile) 또는 내장 감마 및 색도(chromacity) 정보로부터 생성될 수 있다. 이것은 ImageData 클래스 내의 감마 또는 다른 중복 속성들 또는 필드들을 제공할 필요성을 없앤다.
MILRender 코드는 32-bpc 칼라 사양(scRGB)를 이해한다. 입력 칼라 변환은 렌더링 코드 위에서 발생해야 한다(그러나 관리되지 않는 코드를 벗어날 필요는 없다).
칼라 값들의 애니메이션은 주로 선형 공간에서 발생한다. 이것은 선형화된 HSV 공간 또는 scRGB일 수 있지만, 이해가능하도록, "바운스(bounce)" 및 다른 채널-당(per-channel) 애니케이션에 대해 선형일 것이다.
3개의 칼라 충실도 모드(color fidelity mode)가 아래에 설명된다:
풀(Full) - 시스템을 통해 32bpc; 128bpp 백 버퍼 / 10 bpc+프론트 버퍼; 풀 32bpc 합성.
하이브리드(Hybrid) - 32bpc 칼라 사양/보간; 칼라들을 32bpp 사전 합성으로 디더링(dithering) 또는 클램핑한다.
레거시(Legacy) - 32bpc 칼라 사양 - 32bpp로 즉시 변환됨; 32bpp 합성/출력
이 모드들은 2개의 백 버퍼 포맷, 즉 128-bpp 1.0 감마(scRGB) 및 32-bpp 2.2 감마(sRGB)에 의해 지원된다. 보다 낮은 비트-깊이(16 및 8 bpp 디스플레이) 프론트 버퍼 시나리오들을 처리하기 위한 지원도 제공된다. 백 버퍼는 합성에 있어서의 손실을 방지하기 위해 Present 상에서 디더링된다.
객체들의 형상 클래스는 펜 및 브러시를 가진 2D 벡터 기반 데이터의 클립핑, 히트 테스팅 및 렌더링에 사용될 수 있다. 도출되는 형상 클래스들은 보다 특정적인 구축 및 열거 시맨틱들을 제공한다. 보다 복잡한 모양의 형상의 명시적 정의를 허용하는 일반 PathGeometry뿐만 아니라 많은 모양 특정 형상 타입들(shape-specific Geometry types)이 제공된다. GDI+에 친숙한 것들에 대해 이것은 GraphicsPath와 가장 유사하다.
| 교과서 | GDI+ | 본 발명 |
| Path | GraphicsPath | PathGeometry |
| SubPath | GraphicsPath | PathFigure |
형상은 추상 기본 클래스이다.
형상에 적용되는 변환을 설정하기 위하여 변환 속성(Transform property)을 설정한다.
GeometryCollection은 다수의 형상 객체들의 컬렉션인데, 이들은 이들의 정의 영역 상의 특정 부울 연산을 이용하여 조합된다. 이 객체는 PathGeometry 내의 엄격한 PathFigure 객체들을 사용하여 가능한 것보다 쉽게 형상 객체들의 비주얼 조합들의 구축을 허용한다.
조합 모드 목록(combine mode enumeration)은 컬렉션 내의 형상 영역의 조합을 지시한다. 부울 연산들, Union, XOR, Intersect는 교환가능(commutative)하며, 따라서 형상들에 순서와는 독립적으로 적용된다. Complement 및 Exclude는 교환이 가능하지 않으며, 따라서 제1 형상과 개별 잔여 형상 사이에 정의된다. 즉, {g1,g2,g3}의 배타 조합은 ((g1 exclude g2) and (g1 exclude g3))로서 적용된다. Complement는 현재 영역이 새로운 영역에서 현재 영역을 제외한 결과로 대체되도록 지정한다. 즉, 현재 영역은 새로운 영역으로부터 제외된다. Exclude는 현재 영역이 현재 영역에서 새로운 영역을 제외한 결과로 대체되도록 지정한다. 즉, 새로운 영역은 현재 영역에서 제외된다. Intersect는 영역들의 교집합(intersection)을 취함으로써 영역들을 조합하는 것을 나타내며, Union은 양 영역의 합집합(union)을 취함으로써 영역들을 조합하는 것을 나타내며, Xor은 양 영역이 아니라 어느 한 영역에 의해 둘러싸인 영역들만을 취함으로써 영역들을 조합하는 것을 나타낸다.
GetOptimizedGeometry()는 가능할 경우 형상 컬렉션을 와해(collapse)시키며, 그 결과는 GeometryCollection일 필요는 없다. 이것은 인접한 사각 형상을 단일 사각 형상으로 조합하거나, 인접 경로 형상 사이의 부울 연산을 수행하여 새로운 경로 형상을 생성하거나, GeometryCollection을 동일한 조합 모드로 평면화하는 등의 최적화를 포함할 수 있다. 형상이 많은 상이한 컨텍스트에서 사용되는 상황에서, 이것은 처리 및 저장의 성능 향상을 제공한다.
다음 샘플은 GeometryCollection을 사용하는 마크업을 나타낸다:
PathGeometry는 PathFigure 객체들의 컬렉션이다. PathFigure 객체들 각각 은 이들의 모양을 실제로 정의하는 하나 이상의 PathSegment 객체로 구성된다. PathGeometry의 채워진 영역은 이들의 채워진 속성을 참으로 설정하는 포함된 PathFigure들을 취하고 FillRule를 적용하여 둘러싸인 영역을 결정함으로써 정의된다. 도 13은 PathGeometry 객체 관계를 나타낸다.
FillRule 목록은 Geometry 내에 포함된 Figure 객체들의 교차 영역들이 Geometry의 결과 영역을 형성하도록 어떻게 조합되는지를 지정한다:
EvenOdd 규칙은 캔버스 상의 한 점의 "내부성(insideness)"을, 하나의 광선을 이 점에서 무한대로 임의의 방향으로 드로잉한 후 그 모양의 세그먼트가 이 광선을 가로지르는 곳들을 조사함으로써 결정한다. 0에서 시작하여 세그먼트가 좌에서 우로 광선을 가로지를 때마다 1을 더하고, 경로 세그먼트가 우에서 좌로 광선을 가로지를 때마다 1을 뺀다. 교차 회수를 계산한 후, 결과가 0이면, 그 점은 경로의 외측에 있으며, 그렇지 않은 경우 내측에 있는 것이다.
NonZero 규칙은 캔버스 상의 한 점의 "내부성"을, 하나의 광선을 그 점에서 무한대로 임의의 방향으로 드로잉하고, 광선이 가로지르는 주어진 모양으로부터 경로 세그먼트들의 수를 계산함으로써 결정한다. 이 수가 홀수이면, 그 점은 내부에 있고, 짝수이면 외부에 있는 것이다.
다른 형상 타입들을 다른 그림들과의 포함을 위해 경로 형상으로 변환하기 위하여, AddGeometry 메소드가 사용된다. 이것은 기하학적으로 입력 형상에 매칭되는 그림을 더한다. 애니메이트되지 않은 형상에 대해 매칭은 정확하지만, 애니메이트된 형상은 변환 손실이 클 수 있다. 큰 변환 손실의 이유는 입력 형상의 애니메이트된 파라미터들이 세그먼트에 맞는 형태에 매칭되지 않기 때문이다.
| Geometry | Lossless/Lossy | Figures |
| LineGeometry | 손실(Lossy) w/animation | StartSegment 및 LineSegment |
| RectangleGeometry | 손실 w/animation | PolyLineSegment |
| EllipseGeometry | 손실 w/animation | ArcSegment 및 ArcSegment |
| GeometryCollection | 손실 w/animation | 여러 종류의 세그먼트 |
| PathGeometry | 손실 w/animation | Arc 및 Quadratic 세그먼트를 제외한 모두 |
결과적인 PathGeometry의 목록 및 구조는 입력 형상에 정확히 매칭되는 것이 보증되지 않는다.
그림 컬렉션은 PathFigure 개체들 및 PathGeometry를 정의하는 주 콘텐츠의 컬렉션이다:
PathFigure는 세그먼트 컬렉션을 정의하는 Geometry의 서브 섹션이다. 이 세그먼트 컬렉션은 2차원 PathSegment 객체들의 단일 접속 시리즈이다. PathFigure는 정의된 영역을 가진 닫힌 모양이거나, 곡선을 정의하지만 둘러싸인 영역이 없는 접속된 세그먼트들의 시리즈일 수 있다. PathFigure 클래스는 PathFigure 객체를 요구하지 않고 명시적인 ArcTo/LineTo/(및 기타) 메소드 호출들로부터 PathFigure의 보다 간단한 구축을 허용하는 다수의 편리 함수(convenience fuction)를 포함한다. 명시적 AddSegment 호출은 구성된 세그먼트를 추가하는 데 사용될 수 있다.
그림은 시작점을 필요로 하는데, 이는 각 세그먼트가 추가될 최종점에 대한 연속성을 유지하기 때문이다. 시작점을 지정하기 위하여 StartAt(pt) 또는 Add(newStartSegment(pt))가 호출된다. 세그먼트들을 추가한 후, 최종점을 시작점 에 연결하는 적당히 닫는 세그먼트를 추가하기 위하여, CloseFigure() 또는 Add(newCloseSegment())가 사용된다. 시작 및 폐쇄 세그먼트들은 세그먼트 컬렉션에 나타난다.
PathFigure가 구축되고 StartSegment가 컬렉션 내의 제1 세그먼트가 아니거나, 존재할 경우 CloseSegment가 컬렉션 내의 최종 세그먼트가 아닌 경우에 예외가 발생한다. StartSegment 및 CloseSegment는 그림 내의 어느 다른 위치에서도 유효하지 않으며, 예외는 완전히 빈 세그먼트 컬렉션이다.
PathFigure.IsFilled 속성은 닫힌 그림의 포함된 영역이 히트 테스팅, 렌더링 및 클립핑에 사용되는지의 여부를 명시적으로 제어한다. 이 속성이 거짓으로 설정되는 경우, PathFigure의 윤곽(outline)만이 사용되며, 그의 포함 영역은 PathGeometry의 전체 영역에 이바지하지 않는다. 이 속성의 디폴트 값은 참이다.
PathFigure의 콘텐츠를 점들로 열거하기 위한 하나의 간단한 방법은 그림을 평면화하고 결과적인 PathSegmentCollection을 검사하는 것이다. 평면화 프로세스는 애니메이션 및 곡선 세그먼트 파라미터들과 관련하여 손실이 크지만, 원시 점 데이터(raw point data)는 추가적인 점 처리를 위해 PolyLineSegment를 통해 노출된다.
PathSegmentCollection은 PathSegment 객체들 및 PathFigure를 정의하는 주 콘텐츠의 컬렉션이다.
PathSegment는 PathFigure의 윤곽의 한 섹션을 나타낸다. 간단한 직선 세그먼트, 타원-호(elliptical-arc) 세그먼트, 3차 비지어(cubic bezier) 세그먼트 및 2차 비지어(quadratic bezier) 세그먼트는 PathFigure를 형성하도록 함께 조합될 수 있다.
PathFigure에 추가되는 PathSegment 객체들 각각은 또한 PathSegment.IsStroked 속성을 갖는다. PathSegment가 이 속성을 참으로 설정하는 경우, 특정 PathSegment는 펜으로 렌더링할 때 PathGeometry의 스트로크 영역에 기여한다. 이것은 또한 히트 테스팅 및 PathGeometry의 명시적 Widen에도 적용된다. PathFigure 내의 스트로크된 PathSegment 섹션과 스트로크되지 않은 섹션 사이의 스위칭시의 특정 행동은, 적절한 대쉬 캡들이 PathSegment 단부들에 적용된다는 점에서 지정된 펜이 대쉬한(dashed) 경우와 동일하다.
다음 샘플은 PathGeometry, PathFigure 및 PathSegments를 사용하는 마크업을 나타낸다:
RectangleGeometry는 사각 또는 둥근 코너 사각 형상 객체를 정의한다. 반경 X 및 Y는 둥근 코너들의 축 정렬된 방사상 길이(radical length)를 나타낸다.
다음 샘플은 RectangleGeometry를 사용하는 마크업을 나타낸다:
EllipseGeometry는 축 정렬된 방사상 X 및 Y 길이가 주어진 타원 영역을 정의한다.
다음 샘플은 EllipseGeometry를 사용하는 마크업을 나타낸다:
LineGeometry는 두 점 사이의 선 세그먼트를 정의하며, 따라서 채울 영역을 갖지 않는다.
다음 샘플은 LineGeometry를 사용하는 마크업을 나타낸다.
이미징
ImageSource는 이미징 파이프라인의 기본 빌딩 블록을 포함하는 추상 클래스이다. ImageSource는 개념적으로 소정의 크기 및 해상도로 픽셀들의 일정한 단일 세트를 표현한다. 예를 들어, ImageSource는 Decoder가 제공할 수 있는 이미지 파일 내의 단일 프레임이거나, 그 자신의 소정의 ImageSource 상에서 동작하는 변환 의 결과일 수 있다. ImageSource는 멀티프레임 또는 애니메이트가 아니다. ImageSource는 변경가능한데, 이는 그 자신의 속성이 변경될 수 있어서가 아니라, 그의 서브 클래스들의 속성이 잠재적으로 변경될 수 있기 때문이다.
성능상의 이유로, ImageSource는 IMILBitmapSource 인터페이스를 사용하여 이미지에 대한 관리되지 않는 액세스를 제공하는 것을 지원한다. ImageSource의 서브 클래스가 이것을 제공하지 않는 경우, ImageSource 기본 클래스가 (랩퍼 클래스(wrapper class)를 사용하여) 이것을 제공한다.
ImageData는 ImageSource의 서브 클래스이다. ImageData는 여러 상이한 이미지 소스들에 대한 ImageSource를 구현한다.
ImageData는 디코딩된 이미지를 시스템 메모리에 캐싱하고, 이미지를 지정된 소스 rect로 (캐시로) 절단하고, 이미지를 지정된 디코드 폭 및 높이로 (캐시로) 조절하는 것을 포함하는 서비스를 제공한다. 이미지 디코딩 시나리오에서, ImageData는 입력 스트림 및 마임 타입에 기초하여 어느 디코더를 사용할 것인지의 지정 또는 자동 코덱 발견을 가능하게 한다. ImageData는 URI로부터 직접 이미지를 로딩하는 것을 지원하지 않는다. 로더는 URI를 ImageData를 구축하는 데 사용될 수 있는 스트림으로 맵핑하는 데 사용되어야 한다. ImageData가 구축되면, 그것의 유일한 변경가능 속성들은 그의 내장 썸네일, 그의 메타데이터 및 그의 픽셀 데이터이다. 나머지 속성들은 변경 불가능한 것으로 간주된다.
ImageData의 픽셀 데이터는 예를 들어 2가지 방법 중 하나에 의해, 즉 (1) ImageData에 대한 드로잉 컨텍스트를 취득하고 드로잉 컨텍스트를 통해 명령을 발행하여 이미지 상에 드로잉하거나, (2) ImageData를 VisualManager에 대한 목적지(RenderTarget)로 사용하고 명령을 발행하여 비주얼 트리(장면)를 ImageData로 렌더링함으로써 변경될 수 있다. 어느 경우에나, 드로잉은 메모리 내의 이미지에 대해 행해지는데, 이는 픽셀 데이터가 먼저 디코딩되고 메모리에 캐싱되어야 한다는 것을 의미한다. 캐싱된 메모리 이미지만이 변경되며, (ImageData가 나중에 ImageEncoder를 사용하여 이미지 파일로 인코딩되지 않는 한) 이미지 파일 자체는 영향을 받지 않는다.
ImageDecoder는 디코더에 대한 기본 클래스를 제공하는 추상 클래스이다. 이것은 얼마나 많은 프레임들이 이미지 내에 있는지를 결정하고 프레임들을 열거(또는 인덱싱)하는 방법을 제공한다. 전술한 바와 같이, 이미지 프레임들 각각은 ImageSource이다. 내장 코덱들(built-in codecs)은 각각의 요구된 프레임에 대한 ImageData 객체를 생성한다. 애드-인 코덱(add-in codecs)은 상이한 서브 클래스를 사용하여 각 프레임에 대한 ImageSource를 리턴할 수 있다. ImageDecoder는 ImageSource 자체는 아니지만, 하나 이상의 ImageSource에 대한 컨테이너이다. 이미지의 각 프렘임은 잠재적으로 상이한 특성들(attributes)(상이한 크기, 상이한 해상도 등)을 가질 수 있다는 점에 유의한다.
다수의 내장 디코더는 ImageDecoderBmp.cs, ImageDecoderGif.cs, ImageDecoderIcon.cs, ImageDecoderJpeg.cs, ImageDecoderPng.cs, ImageDecoderTiff.cs, 및 ImageDecoderWmp.cs를 포함하는 MIL을 구비한다. 각각은 다음 예에서와 같이 ImageDecoder, 및 System.IO.Stream을 사용하여 디코더를 초기화하는 단일 구축자를 구현한다.
ImageEncoder는 ImageSource들(이미지 프레임들)의 컬렉션이며, 이들 각각은 잠재적으로 그 자신의 메타데이터 및 썸네일을 갖는다. 프레임들 전체 세트와 관련된 글로벌 썸네일 및 메타데이터가 존재할 수도 있다. 코덱은 또한 이미지를 어떻게 인코딩할 것인지를 결정하는 데 사용되는 인코딩 속성들에 대한 지원을 제공하도록 선택할 수 있다. 프레임들의 컬렉션은 임의 수의 지정된 스트림으로(한번에 하나씩) 저장(인코딩)될 수 있다. 이 컬렉션은 소거(clear)된 후 상이한 컬렉션으로 채워지고 다시 저장될 수 있다.
다수의 내장 인코더는 ImageEncoderBmp.cs, ImageEncoderGif.cs, ImageEncoderIcon.cs, ImageEncoderJpeg.cs, ImageEncoderPng.cs, ImageEncoderTiff.cs, 및 ImageEncoderWmp.cs를 포함하는 MIL을 구비한다.
ImageSizeOption들은 썸네일의 크기 및 캐싱된 이미지들의 크기를 지정하는 데 사용된다. 옵션들은 폭, 높이, 원본 이미지의 종횡비를 유지할 것인지의 여부, 및 회전각(90도의 배수)을 포함한다.
다음은 이미지들 및 픽셀 기반 표면들에 대한 픽셀 포맷 정의를 제공한다.
각각의 코덱(ImageEncoder 및 ImageDecoder)은, 코덱에 대한 정보를 제공하고 그와 관련된 디코더/인코더에 대한 인스턴스 생성 메소드들을 제공하며 이 코덱이 제공된 CodecFilter와 매칭되는지를 결정하는 메소드를 제공하는, CodecInfo를 제공할 것이 요구된다.
내장 CodecInfo 객체들은 CodecInfoBmp.cs, CodecInfoGif.cs, CodecInfoIcon.cs, CodecInfoJpeg.cs, codecInfoPng.cs, CodecInfoTiff.cs, 및 CodecInfoWmp.cs를 포함하는 MIL을 구비한다.
CodecFilter는 지정된 기준에 기초하여 코덱들을 열거하기 위해 코덱 목록기(enumerator)에 의해 사용된다. 지정되지 않은 기준은 매칭 코덱을 찾을 때 무시된다. 예를 들어, MimeType가 설정되지 않은 경우, 임의의 마임 타입을 가진 코덱들이 고려된다.
목록기가 구축될 때, 목록기에는 CodecFilter가 주어진다. 이 필터는 어느 코덱들이 열거되는지를 결정하는 데 사용된다. 필터에 매칭되는 코덱들만이 (존재할 경우) 열거된다.
ImageEffect는 래스터 기반 이미징 효과를 위한 기본 클래스이다. ImageEffect는 0개 이상의 입력 및 0개 이상의 출력의 컬렉션으로서 관측될 수 있 다. ImageEffect에 대한 입력 및 출력은 모두 ImageSource 타입이다. ImageEffect는 일반적으로 그의 입력 및 그의 속성으로 초기화된 후, 그의 출력이 장면의 일부를 드로잉하는 데 사용되거나 ImageEncoder에 대한 프레임들로서 사용된다. 내장된 효과들은 ImageEffectBlur, ImageEffectFlipRotate, ImageEffectGammaCorrect, ImageEffectGlow, ImageEffectGrayscale, ImageEffectNegate, ImageEffectSharpen, ImageEffectTint를 포함하지만 이에 제한되지 않는다.
변환
도 7에 도시된 객체들의 Transform 클래스는 벡터 및 래스터 그래픽의 스케일링, 회전, 이동(translating) 및 왜곡(skewing)에 사용될 수 있다. 도출되는 변환 클래스들은 친숙한 사용 및 열거 시맨틱을 제공한다. 변환 클래스 계층 구조는 클래스이고 애니메이션 및 열거 시맨틱을 지원한다는 점에서 Matrix struct와는 다르다:
TransformCollection (enumerating semantics, etc.)
TransformCollection.AddScale(...)
Animate MatrixTransform
Transform은 추상 기본 클래스이다:
TransformCollection은 개별 Transform 값들의 행렬 승산인 값을 갖는 Transform 객체들의 컬렉션이다. 이 값은 좌에서 우로 구성되고, 컬렉션의 최초 및 최종 항목에 매칭된다:
RotateTransform은 특정 중심점(디폴트는 0,0)에 대한 각도의 회전을 정의한다. 각도는 도(degree)로 지정된다. 점 x,y에 대한 회전각의 정적 행렬 표현은 다음과 같다.
TranslateTransform은 x 및 y 방향으로의 축 정렬 이동을 정의한다. 오프셋 dx, dy에 의한 이동의 정적 행렬 표현은 다음과 같다.
ScaleTransform은 중심점(디폴트는 0,0)에 대한 x 및 y 방향의 스케일을 정의한다. 점 x, y에 대한 스케일 sx, sy의 정적 행렬 표현은 다음과 같다.
SkewTransform은 x 및 y 방향을 따른 각도에 의한 왜곡을 정의한다. 왜곡 각도는 도이다. 각도에 의한 왜곡의 정적 행렬 표현은 다음과 같다.
MatrixTransform은 변환을 그 수학적 표현을 통해 정의한다:
Transform 타입 속성이 마크업에서 지정될 때, 속성 시스템은 Transform 타입 변환기를 사용하여 스트링 표현을 적절한 Transform 도출 객체(Transform derived object)로 변환한다. 현재 이 신택스를 사용하여 애니메이트된 속성들을 설명할 방법이 없다.
신택스는 벡터 그래픽 내에 있으며, 대응하는 Transform 구축은 다음과 같이 요약되는데, 여기서 "<>"로 표시된 파라미터들은 선택적인 파라미터를 나타낸다:
효과
효과는 렌더링 중심 방식으로 장면의 비주얼 콘텐츠를 변경하는 수단을 제공한다. 예를 들어, ImageEffect들(래스터 기반 비트맵 효과들)은 장면의 일부에 대한 이미지 기반의 완전히 합성된 표현 상에서 동작한다. 효과들은 ImageEffect, Blendmode 및 VectorEffect를 포함하는 다양한 타입으로 분류된다.
ImageEffect는 서브 그래프 또는 Element에 적용함으로써 유지 모드 장면에서 사용되거나, 독립식(standalone) 이미지 파이프라인에서 사용될 수 있다. 일반적으로, ImageEffect는 ImageSource 타입인 0개 이상의 입력과 0개 이상의 출력을 갖는다. 즉석 모드 이미지 파이프라인에서, ImageEffect는 그의 입력의 특성들을 설명하는 다른 속성들을 표면화할 수 있으므로 출력이 존재할 필요는 없다. 예를 들어, ImageEffect는 칼라 히스토그램 정보 또는 표면 검출 정보(face-detection information)를 방출할 수 있다. 유지 모드 장면에서는, 효과가 적용되는 서브 그래프의 렌더링된 콘텐츠에 대한 액세스를 제공하는 추가적인 메타 입력이 존재한다.
BlendMode는 이미지 기반 효과들의 특정 형태이다. 이들은 일반적으로 ImageEffect와 동일한 방식으로 유지 모드 장면에 적용될 수 있다. 따라서, Visual 상의 BlendMode 속성, IDrawingContext 상의 PushBlendMode 메소드 및 Brush 상의 BlendMode 속성은 물론 Element 속성("BlendMode")이 존재한다. Blend 모드는 소스가 합성될 때 소스 및 목적 칼라들의 조합을 수행한다. Blend 모드의 예는 승산, 가산 등을 포함한다. VectorEffect는 또 하나의 효과 타입이다. Overview에서 설명된 바와 같이, BlendMode는 하나의 이미지가 또 하나의 이미지에, 또는 장면에 합성되는 방법을 제어하는 연산을 나타낸다. BlendMode는 장면 및 브러시에 적용될 수 있다. 각 BlendMode는 소스 픽셀과 목적 픽셀을 조합하는 방법을 설명하며, 합성되고 있는 모든 픽셀에 적용된다. BlendMode는 소스가 스케일링되거나 변환된 후에, 그리고 임의의 효과가 적용된 후에(Opacity 포함) 적용된다. BlendMode 연산이 적용될 때 소스 및 목표는 사전 승산된 알파 포맷을 갖는다는 점에 유의한다. BlendMode를 지정하기 위하여, 프로그래머는 BlendMode 정적 클래스에서 지정된 BlendMode들 중 하나를 사용하거나, 소스 및 목적 승수(destination multiplier)를 명시적으로 설정할 수 있다. 일 실시예에서 승수는 확장 가능하지 않고 파라미터를 갖지 않으므로, 목록으로 표현된다:
히트
테스팅
히트 테스팅은 장면에서 비주얼들을 채집하는 데 사용된다. 몇몇 하이 레벨 시나리오는 래소(lasso) 선택 및 러버 대역(rubber band) 선택, 키보드 네비게이션(초점을 전환할 다음 요소를 발견하는 데 사용됨), 요소 트리 내의 마우스 초점의 결정, 투명한 중첩 요소들(예를 들어 이미지)의 선택, "사고 버블(thought bubble)" 히트 테스팅 및 텍스트 내의 문자 히트 선택을 포함한다.
일반적으로, 히트 테스팅은 코어, 프레임워크 및 제어에 대해 일관성을 제공하며, 제어 트리의 최상부에서 시작하여 점 또는 형상에 의해 제어 또는 제어 세트를 리턴함으로써 동작한다. 제어는 이것이 히트인지 또는 렌더링된 형상, 경계 박스, 대역외 형상(히트 영역), 이미지 불투명 또는 마스크 및 그 자신의 로직을 포함하는 지원 서비스들을 갖는 않는지를 정의할 수 있다. 제어는 히트에 관한 특정 히트 관련 데이터(예를 들어 선, 문자 위치 등)를 리턴할 수 있다.
히트 테스트 메커니즘은 히트 테스트 결과들을 효율적인 방식으로 필터링할 수 있다. 또한, 히트 테스트 메커니즘은 다른 타입들의 비주얼들로의 확장 및 비주얼 내의 서브 원시함수들로의 분해(resolving down)를 위한 유연성을 제공하는데, 예를 들면 Retained3DVisual이 그 일례이다.
히트 테스트 워크는 비주얼 트리의 깊은 우에서 좌로의 워크이다. 3개의 참여자, 즉 히트 테스터, 워커 및 제어/비주얼이 존재한다. 히트 테스터는 2개의 콜백, 즉 워커(walker)를 조정하기 위한 콜백 및 소정의 히트 비주얼 상에서 일찍 워크를 종료하기 위한 콜백을 구현한다. 제어는 무엇이 히트인지를 정의하기 위한 가상 메소드를 구현한다. 워커는 시스템의 고정 부분이며, 콜백 행동에 기초하여 비주얼 트리를 워킹하여, 본질적으로 각각의 제어에게 제어가 히트되었는지를 문의한다. 히트들 z 순서, 상하 방식으로 콜백을 통해 보고된다.
내부적으로, 히트 테스팅은 비주얼 트리의 워크를 포함한다. 내려갈 때, 히트 테스터는 요소 레벨 관계들, 예를 들어 모양들을 가진 캔버스 또는 내부 캔버스 를 가진 도크 패널에 의해 필터링을 관측한다. 히트가 발생할 때, 히트 테스터는 추가 히트(있을 경우)를 계속 처리하거나 중지할 수 있다.
히트 워커 관점에서의 제어 흐름 로직은 다음의 의사코드를 갖는다:
히트 테스터는 공개 메소드를 사용하여 히트 테스트를 개시하며, 행동을 제어하기 위한 델리게이트를 제공한다. 디폴트 행동은 모든 비주얼에 대해 테스트하고 제1 히트를 리턴하는 것이다. 결과 델리게이트가 주어지지 않는 경우, 예외가 발생한다.
제어는 점 및 형상에 대한 HitTestCore를 오버라이드함으로써 그의 히트 테스트 로직을 결정한다. 히트 테스트가 개시될 때, 내부 비주얼 트리 워커는 HitTestCore 호출하여, 제어에 대하여 그것이 사실상 히트인지를 문의한다. HitTestBound들은 히트 영역의 타이트한 경계들을 반사하며, 워크를 최적화하는 데 사용된다. 디폴트 비주얼 행동은 렌더 콘텐츠 경계 박스를 테스트하는 것이다. 디폴트 히트 경계들은 렌더 콘텐츠 경계 박스이다.
히트 테스터는 히트 점 또는 형상 및 HitTestParameters 내의 추가 파라미터들을 전달함으로써 히트 테스트를 개시한다. 클래스는 주로 설계를 단순화하고 확장성이 순행(go forward)하는 것을 허용하기 위해 제공된다. 특수 히트 테스팅 요구들이 이 클래스로부터 도출되어 추가 정보를 관련 제어들에 전달할 수 있다. 각각의 제어는 점 및 형상에 대해 특정 HitTestCore를 구현한다. 제어들은 그들의 HitTestCore 로직을 구현할 때 히트 테스팅 파라미터들을 고려할 것으로 예상된다.
제어는 HitTestResult로부터 도출함으로써 특정 데이터를 리턴한다. 예를 들어, 텍스트 제어는 문자 위치 히트를 리턴하기를 원할 수 있다. PointHitTestResult는 로컬 좌표 공간점을 포함한다. GeometryHitTestResult는 (오리지날 히트 테스트의) 로컬 좌표 공간 형상을 포함한다. 비주얼 변환 함수들은 히트 위치를 조상 공간에 맵핑할 수 있다.
델리게이트의 사용을 설명하기 위하여, 익명의 델리게이트를 이용하여 제1 최상 히트를 원하는 히트 테스트를 고려한다.
또 하나의 예는 히트된 비주얼들 모두를 리턴하기를 원하는 히트 테스트이다.
히트 테스터는 목록(enum)을 사용하여 히트 테스트 필터링 및 결과 행동을 제어한다.
HitTestFilterBehavior 목록은 SkipChildren의 지정이 이 비주얼을 히트 테스트하지만 그의 자식 비주얼은 히트 테스트하지 않는다는 점에서 필터링 행동을 제어한다. SkipVisualAndChildren은 비주얼도 자식 비주얼도 히트 테스트하지 않도록 지정한다. SkipVisual은 비주얼은 히트 테스트하지 않지만 임의의 자식 비주얼들은 히트 테스트하도록 지정한다. Continue는 이 비주얼 및 그의 자식 비주얼들을 히트 테스트하도록 지정한다. Stop은 비주얼 트리 내의 임의의 비주얼들을 히트 테스트하지 않고 호출자에게 리턴하도록 지정한다.
HitTestResultBehavior 목록은 히트 테스트 행동을 제어한다.
Stop은 히트 테스트 엔트리로 리턴하도록 지정하고, 임의의 추가적인 필터 또는 히트 테스트 연산을 스킵한다. Continue는 다음 비주얼을 히트 테스트하도록 지정한다.
히트 테스트 식별자들이 포지티브 히트 식별을 위해 특정 콘텐츠를 표시하는 데 사용될 수 있지만, 이러한 모델은 렌더 스트림을 분해하고 워크 오버헤드에 추가하고 히트 테스팅 시에 관리하기가 어렵게 때문에 성능은 열악하다. 요소와 비주얼을 통합 타입으로 조합함에 있어서, 입도의 기본 레벨은 비주얼 그 자체이며, 제어들은 이들이 원하는 입도의 레벨을 얻도록 그 자신들을 구성할 수 있다.
제어 작성자는 HitTestCore를 무시하고 그 자신의 연산을 행하고, 그리고/또는 후술하는 서비스들을 이용함으로써 히트에 대한 로직을 작성한다.
다음은 이들 서비스의 효력을 나타내는 몇몇 예이다.
제1 예는 제어의 히트 민감 영역을 나타내는 공개 HitRegion 속성을 가진 제어를 나타낸다. 히트 영역은 렌더링된 콘텐츠에 매칭할 필요가 없으며, 몇몇 애플리케이션들에 의해 최적화될 수 있다는 점에 유의하자. 히트 영역이 설정되지 않은 경우(_hitRegion==null), 제어는 히트를 결정하기 위한 기본 구현 서비스로 연 기(defer)한다.
IsHit 행동을 무시하기 위하여 추가적인 지원 서비스를 이용한다.
형상 클래스들은 그의 내부 영역에 대해 히트 테스트를 수행한다.
비주얼은 (그 자체의) 렌더링된 콘텐츠를 히트 테스트하기 위한 보호된 함수를 제공한다. 비주얼이 유지되는 경우, 이것은 콘텐츠 검증(content validation)을 트리거링한다. 이러한 헬퍼(helper)는 비주얼 상에 저장된 드로잉 명령 스트림을 한번에 한 명령씩 검사하며, 렌더링된 형상으로 각각에 대한 점 또는 형상을 히트 테스트한다.
코드는 이 점의 이미지 픽셀이 알파 임계치(alpha threshold)를 넘는 경우에 리턴한다. 이 점은 비주얼 공간 내에 있으며, 변환은 픽셀 기반 테스트가 발생하는 장치 공간에 대한 것이다.
공개 클래스 ImageData: ImageSource
애니메이션
애니메이션 시스템은 2개의 주요 컴포넌트 세트, 즉 타이밍 제어 엔진 및 애니메이션 객체 세트를 포함한다. 타이밍 엔진은 시간 가변 행동을 나타내는 임의의 객체들에 의해 이용될 수 있는 서비스인데, 그 주요 예는 애니메이션 및 오디오 또는 비디오 객체들이다. 애니메이션 객체들은 시간 간격을 다른 데이터 타입으로 맵핑하는 한 세트의 함수를 구현하는데, 이들은 다른 보다 높은 레벨의 객체들로의 입력으로 사용된다.
그래픽 애니메이션은 애니메이션 컬렉션을 렌더링 연산과 연관시킴으로써 달성된다. 예를 들어, IDrawingContext.DrawLine 메소드는 하나의 펜 및 2개의 종점을 취한다. 종점들 중 하나는 PointAnimation 객체들의 컬렉션과 연관될 수 있는데, 이 경우에 선은 시간에 따라 움직인다. 마찬가지로, 펜은 연관된 ColorAnimation 객체들의 컬렉션을 가질 수 있다. 이들 경우에, 렌더링 연산에 사용되는 각 애니메이션은, 종종 "타임라인"으로 지칭되는 개별 클록 상에서 실행될 수 있다. 애니메이트된 원시함수가 드로잉되는 경우, 렌더링 시스템은 규칙적인 간격으로 장면의 리드로잉을 처리한다. 프레임이 렌더링될 때마다, 장면에 수반되는 애니메이션들의 현재 값이 경과 시간(대부분의 경우 시스템 클록에 의해 측정됨)에 기초하여 계산된 후, 애니메이트된 원시함수가 리드로잉된다.
애니메이션들의 프로그래밍은 시스템에 의해 제공되는 애니메이션 객체들 및 이들 애니메이션을 구동하는 타이밍 엔진에 대한 이해를 필요로 한다. 다음 용어들은 이 섹션의 여러 곳에서 사용된다.
타이밍 모델이 제공되는데, 이 모델에서 타이밍된 객체들은, 개별 타임라인들이 이들의 부모 타임라인, 또는 최상위 레벨 타임라인들에 대해서는 루트 "문서"(또는 "페이지", 또는 "프레임") 타임라인에 대한 이들의 행동을 정의하는 특성들을 갖는, 계층적 타이밍 시스템에 참여한다. 타이밍 특성들은 객체의 시간 행동을 정의하는 한 세트의 파라미터들이다. 타이밍 특성들은 배타적으로 설명적이며(exclusively descriptive), 실행 시간 상태를 갖지 않는다. 또한, 타이밍 특성들은 변경 불가능하다.
타임라인은 한 세트의 타이밍 특성들에 따라 실행 시간 상태를 유지하는 타이밍 엔티티의 한 예이다. 타임라인은 타이밍된 객체에 대한 "현재(now)"의 개념을 정의한다. 타이밍 트리는 계층적인 방식으로 배열된 한 세트의 타임라인들을 포함하는 데이터 구조이다. 타임라인들 사이의 관계는 한 세트의 상속 규칙들에 의해, 그리고 각각의 타임라인과 관련된 타이밍 특성들에 의해 정의된다.
타이밍된 객체는 시간 가변 행동을 나타내는 임의의 객체이다. 타이밍된 객체의 시간 행동에 대한 설명은 한 세트의 타이밍 특성들에 의해 지정되는 반면, 그 의 실행 시간 타이밍 상태는 하나 이상의 타임라인에 의해 유지된다. 애니메이션 함수는 특정 데이터 타입의 기본 값을 입력으로서 취하고 동일 타입의 값을 그의 출력으로 생성하는 함수이다. 애니메이션 함수는 Timeline의 현재 시간 값과 같은 다른 암시적 또는 명시적인 입력 파라미터들을 취하거나 취하지 않을 수 있다. 이 점에서, 애니메이션 함수는 동일 입력이 다른 시간에 다른 출력들을 생성할 수 있으므로 일정할 수 없다.
수정자(modifier)는 애니메이션 함수를 구현하는 객체이며, Element의 속성 값, 소정의 다른 복합 객체, 또는 렌더링 호출에 대한 파라미터를 수정하는 데 사용된다. 타이밍된 수정자는 타임라인과 관련된 수정자이며, 이 수정자의 애니메이션 함수는 명시적으로 그 타임라인의 실행 시간 상태에 의존한다. 애니메이션은 소정의 공지 세트의 애니메이션 함수들을 구현하는 타이밍된 수정자이다.
애니메이션 컬렉션은 동일 데이터 타입을 처리하는 수정자들의 컬렉션이다. 애니메이션 컬렉션은 수정자의 출력을 다른 수정자의 입력에 연결시켜, 수정 파이프라인을 생성한다. 전체 컬렉션은 하나의 입력을 취하고 하나의 출력을 생성하므로, 컬렉션 자체는 하나의 수정자로서 행동한다.
타임라인들은 비디오 클립 또는 애니메이션의 재생과 같은 시간 가변 프로세스들을 제어하는 스톱워치들로서 간주될 수 있다. 타임라인의 특성들에서 지정되는 시간들은 무언가와 관련된다. 대부분의 경우, 이들은 부모 타임라인과 관련되나, 트리의 루트에 있는 타임라인들에 대해서는 이 값들은 "문서 시간"과 관련되는데, 이 문서 시간은 애플리케이션이 론칭(launching)될 때, 또는 페이지 또는 프레 임이 네비게이트될 때 시작되는 암시적인 타임라인이다. 타임라인 내의 클록은 2가지 방법으로, 즉 시작점으로부터의 오프셋으로서, 또는 0과 1 사이의 진행 비로서 노출된다. 후자는 단순히 현재 시간 대 지속 기간의 비이다.
가장 간단한 타임라인은 시작 시간과 지속 기간을 갖는다. 예를 들어, 3초의 시작 시간과 3초의 지속 기간을 갖는 타임라인은 기준 t=0 시간에서 3초 후에 시작되어(디폴트로 모멘트 애플리케이션이 로딩됨), 5초 후에 종료한다. 이 5초 동안, 타임라인은 "온"이라고 한다. 이 타임라인이 애니메이션을 제어하는 경우, 이 애니메이션은 그 시간 동안 변경(예를 들어 이동)되고 있지만, 그 전후에는 정적이다. 도 29는 3초의 시작 시간과 5초의 지속 기간을 가진 타임라인을 나타낸다.
타임라인은 또한 그의 행동을 반복하도록 프로그래밍될 수 있다. 이 반복은 반복 회수 또는 반복 지속 기간으로 지정될 수 있다. 타임라인은 요구된 회수 또는 지속 기간을 채우기 위해 필요한 만큼 많은 시작/종료 실행을 행한다. 반복 회수가 정수 값이 아닌 경우, 최종 반복은 중간에서 중단된다. 도 30은 시작=3, 지속기간=5 및 반복 지속 기간=17(애니메이션이 시작 시간 후 17초 또는 20초까지 5초마다 반복되는 것을 의미)를 가진 타임라인을 나타낸다.
타임라인의 시작 시간은 통상적으로 그의 부모 타임라인에(또는 문서 시간에) 관련되지만, 다른 타임라인의 시작 또는 종료와 관련하여 시작 시간이 지정될 수도 있다. 이러한 상황에서는, 소스 타임라인의 모든 시작(또는 종료)은 대응하는 시작이 목표 타임라인에 대해 스케쥴링되게 한다. 도 31은 다른 것의 타임라인 3초 후의 시작 시간을 갖는 타임라인을 나타낸다.
타임라인은 종점에 도달할 때 즉시 턴오프된다. 이때, 타임라인이 제어하는 타이밍된 객체는 프리젠테이션에 효과를 갖도록 멈춘다. 예를 들어, 타이밍된 객체가 애니메이션인 경우, 제어 타임라인이 종점에 도달할 때, 애니메이션은 제거되는데, 즉 애니메이션은 그의 기본 값으로 복귀한다. 그러나, 애니메이션의 최종 정상 상태를 최종 값으로 고정시키는 것이 바람직한 경우가 있다. 즉, 타임라인은 시점과 종점 사이에서 0에서 1로 진행하지만, 종점 후에는 타임라인이 1의 진행과 함께 "온" 상태로 유지된다. 이것은 "채움(fill)" 행동이라고 한다. 도 32는 시작=3, 지속기간=5 및 채움(Fill)=고정(Freeze)을 가진 타임라인을 나타낸다.
시간은 타임라인의 시점에서 0의 진행 값으로부터 1의 진행 값으로 선형으로 흐른다. 그러나, 타임라인 내의 시간의 경과와 그의 부모 내의 시간의 경과 사이의 관계는 디폴트 직접 상관(default direct correlation)으로부터 변경될 수 있는데, 이는 시간이 타임라인에서 역행하여 뒤로 흐르는 것으로 보일 수 있고, 시간이 흐르는 속도가 승산 계수(multiplicative factor)에 의해 빨라지거나 느려질 수 있으며, 그리고/또는 진행 곡선이 변형되어(morphed) 0에서 1로 선형으로 진행하는 대신에 시점에서의 정지에서 최대 진행 속도로 가속된 후 종점에서의 정지를 향해 감속되기 때문이다. 이것은 이 타임라인에 의해 제어되는 임의의 애니메이션들에 대해 "이즈 인, 이즈 아웃(ease-in, ease-out)" 효과를 생성한다.
더욱 구체적으로, 진행/시간 곡선은 디폴트로 선형이다. 이 선형 곡선이 소정의 애니메이션을 제어하는 데 사용될 때, 사용자는 시점과 종점에서 "저크 (jerk)" 효과를 느끼게 되는데, 이는 애니메이션이 갑자기 시작되고 종료되기 때문이다. 이들 경우에, 타임라인은 유연한 가속 곡선을 이용하여 정지에서 최대 속도로 시간의 진행을 가속하도록 프로그래밍될 수 있다. 마찬가지로, 시간은 종점 근처에서 0을 향해 감속되도록 프로그래밍될 수 있다. 가속 및 감속 효과는 가속 또는 감속 단계에서 소모되는 지속 기간의 퍼센트로 지정된다. 2개의 값은 양이며, 이들의 합은 1을 초과하지 않는다. 도 33은 시작=3, 지속기간=10, 가속도=0.2 및 감속도=0.4를 갖는 타임라인을 나타낸다.
하나의 간단한 시간 조작은 0의 진행 값에서 1로 간 후 다시 0으로 가도록 타임라인을 프로그래밍하는 것이다. 이 경우, 타임라인은 지정된 지속기간의 2배 동안 두 번, 즉 "순방향" 부분 동안 한번, "역방향" 부분 동안 한번 활성화된다. 도 34는 시작=3, 지속기간=5 및 AutoReverse=True를 갖는 타임라인을 나타낸다.
타임라인에 대한 명백한 시간의 경과는 일정한 계수로 그의 부모보다 빠르거나 느릴 수 있다. 디폴트로 이 계수는 1이며, 이는 타임라인 및 그의 부모에서의 시간이 동일한 속도로 흐른다는 것을 의미한다. 대신 이 값이 1보다 크면, 타임라인의 시간이 그의 부모보다 빠르게 진행한다. 예를 들어, 3의 계수는 타임라인이 지정된 지속기간보다 3배 빠르게 시점과 종점 사이에서 진행하게 만든다. 역으로, 계수가 0과 1 사이이면, 시간은 느리게 흐른다. 계수가 음이면, 타임라인의 시간은 항상 그의 부모에 대해 뒤로 흐르는 것으로 보인다. 시작 시간 자체는 부모 타임라인의 기준 프레임에서의 오프셋이라는 점에 유의한다. 결과적으로, 타임라인의 지속기간이 속도 계수에 의해 영향을 받지만, 시작 시간은 그렇지 않다. 도 35 는 시작=3, 지속기간=5 및 속도=0.5인 타임라인을 나타낸다.
타임라인들은 트리 구조로 체계화될 수 있다. 모든 문서, 프레임 또는 윈도우는 소정의 암시적인 "루트" 타임라인을 갖는데, 이는 실세계의 벽시계 시간을 표현하는 것으로 생각될 수 있다. 그러나, 루트 타임라인의 시간 t=0은 그 타임라인이 생성되는 시간, 즉 문서가 로딩되거나, 프레임이 내비게이트되거나, 윈도우가 열리는 시간이다.
타이밍 시스템의 계층적 본질이 주어지면, 이는 3개의 기준 프레임 중 하나에서 발생하는 시간의 경과를 나타내는 것으로 이해된다. 간단한 기준 프레임은 개별 타임라인이 경험하는 기준 프레임이다. 이 기준 프레임에서, 타임라인의 진행 값은 항상 t=0에서 0이고 t=d에서 1인데, 여기서 d는 타임라인의 단순한 지속기간이다. 타임라인의 지속기간은 항상 간단한 기준 프레임에서 지정된다. 부모 타임라인의 기준 프레임은 임의의 주어진 타임라인의 부모인 타임라인에 대한 간단한 기준 프레임이다. 예를 들어, 타임라인의 시작 시간은 항상 부모 타임라인의 기준 프레임에서 지정된다. 글로벌 기준 프레임은 루트 타임라인의 간단한 기준 프레임이다. 이 기준 프레임에서, 시간 t=5초는 타임라인이 생성되고 5초 후에 발생하며, 10초의 지속기간이 정확하게 실세계의 10초 동안 지속된다.
또한, 타임라인이 활성인 경우, 그의 부모 타임라인도 활성이어야 하는 것을 포함하여 다양한 타이밍 제어 규칙들이 타이밍 서브 트리에 적용된다. 역으로, 타임라인이 활성이 아니면, 그의 자식들 중 어느 것도 활성일 수 없으며, 어느 것도 시작될 수 없다. 타임라인이 명시적으로 중지되면(ITimingControl.Pause 메소드에 대한 호출을 통해), 그의 자식들도 명시적으로 중지된다. 타임라인이 재개될 때, 명시적으로 중지되지 않았던 그 자식들 중 어느 하나도 재개된다. 타임라인이 시작되면(반복점을 가로지르는 것을 포함하는 다양한 이유 중 하나로), 그 자식들은 리셋된다.
타임라인은 명시적으로 다른 타임라인의 부모가 될 수 있는데, 이 경우에 타이밍 트리의 모양은 명시적이고 분명하다. 그러나, 많은 경우에 소정의 디폴트 타이밍 부모에 기초하여 시스템이 자동적으로 타임라인의 부모가 되게 하는 것이 유용하다. 명시적으로 부모화(parented)가 되지 않은 타임라인은 자동으로 부모화가 되며, 그의 유효 부모 타임라인은 타임라인이 어떻게 사용되는가에 의존한다. 비주얼 부모에 대한 부모화 및 루트에 대한 부모화라고 하는 2가지 타입의 자동 부모화가 지원된다.
타임라인의 비주얼 부모는 타임라인이 어떻게 사용되는가에 의해 암시적으로 결정된다. 예를 들어, 타임라인이 칼라 애니메이션을 제어하고, 이 칼라 애니메이션이 소정의 비주얼 V의 백그라운드로 사용되는 브러시를 애니메이트하는 경우, V는 그 타임라인의 "비주얼 부모"이다. 이 비주얼이 관련 디폴트 타임라인을 갖는 경우, 이 타임라인은 이 예의 원 타임라인의 부모이다. 그렇지 않으면, 비주얼의 부모는 반복적으로(recursively) 검사된다. 비주얼 트리의 루트는 항상 루트 타임라인과 암시적으로 관련되며, 따라서 비주얼이 비주얼 트리 내에 있는 경우, 그 안의 임의의 자동 부모화 타임라인들은 타이밍 트리 내의 어딘가에서 부모화가 되는 것이 보장된다. 그러나, 비주얼이 아직 비주얼 트리 내에 있지 않은 경우에는, 그 의 타임라인들은 비주얼이 트리 내에 삽입되는 시간까지 타이밍 트리의 외부에 남아 있는다.
디폴트 "루트" 타임라인은 또한 비주얼 부자 관계에 의해 정의되는데, 이 경우에 타임라인을 갖는 가장 가까운 비주얼 부모가 반드시 사용되지는 않는다는 점은 예외이다. 오히려, 루트 부자 관계에서, 타임라인은 항상 트리 내의 가장 높은 비주얼(프레임 또는 윈도우 객체, 또는 VisualManager와 연관된 루트 비주얼일 수 있다)과 연관된다.
타임라인이 자동적으로 부모화되면, 암시적인 디폴트 부모 타임라인을 변경하는 어떤 일이 발생할 경우 이 타임라인은 다시 부모화 되어야 할 필요가 있을 수 있다. 예를 들어, 타임라인의 즉석 비주얼 부모가 초기에 그 자신의 디폴트 타임라인을 갖지 않았지만 그 후에 하나가 설정된 경우, 타임라인은 다시 부모화 되어야 한다. 이러한 재부모화(re-parenting)는 자동으로 발생한다. 자동 부모화 및 재부모화는 후술하는 IAnimatable 인터페이스에 의해 구현된다.
타임라인들 및 타이밍된 객체들은 다수의 행동을 공통으로 공유한다. 예를 들어, 애니메이션은 중지되거나 재개될 수 있으며, 애니메이션들의 리스트는 활성 또는 불활성일 수 있다. 일관성을 유지하기 위하여, 타이밍된 객체들은 타이밍 메소드 및 속성에 대한 액세스를 허용하는 하나 이상의 인터페이스를 구현한다.
ITimingControl 인터페이스는 실행시간에 제어될 수 있는 타이밍된 객체들에 의해 구현된다:
다음의 표는 ITimingControl 인터페이스의 시맨틱들을 요약한 것이다.
메소드, 속성 또는 이벤트 의미
Acceleration 시간 가속 단계에서 소모되는 단순 지속기간의 비 율을 나타내는 0과 1 사이의 값이다. 이 특성 및 감속 특성의 합은 1을 초과할 수 없다.
AutoReverse 이 특성이 참인 경우, 타임라인은 시작에서 끝으로 진행한 직후 다시 끝에서 시작으로 진행한다. 이 경우, 타임라인은 지속기간 특성에 의해 지정되는 시간량의 2배 동안 활성화된다.
Begin 이 타임라인이 시작되어야 하는 시간이다. 디폴트 로, 이 시간은 부모 타임라인의 시작 시간과 관련 되지만, 소정의 다른 타임라인의 시작 또는 종료 시간에 대한 오프셋이 지정될 수도 있다. 후자의 경우, 그 다른 타임라인은 이 타임라인과 동일한 타임라인의 자식이 된다.
BeginIn 미래 또는 과거의 지정된 시점에서 상호작용 시작 을 트리거한다. 이 파라미터는 이 타임라인의 부 모 타임라인의 기준 프레임 내에 있다. 부모 타임 라인이 활성이 아닌 경우, 이 메소드는 어떠한 효 과도 갖지 않는다.
Begun 객체가 그의 내부 상태가 계속 변하는 기간에 들어 갈 때마다 발생한다.
Changed 수정자에 의해 그의 내부 상태가 변할 때마다 발생
Ended 객체가 그의 내부 상태가 계속 변하는 기간을 벗어 날 때마다 발생한다.
CurrentRepeat 타임라인이 반복되는 경우 타임라인의 현재의 반 복. 제1 반복은 반복 1이다. IsOverridingBaseValue가 거짓인 경우 이 속성은 0 을 리턴한다.
CurrentTime 이 타임라인에 로컬한 현재 시간. IsOverridingBaseValue가 거짓인 경우, 이 속성은 Time.Unspecified를 리턴한다.
Deceleration 시간 감속 단계에서 소모되는 단순 지속기간의 비 율을 나타내는 0과 1 사이의 값이다. 이 특성과 가속 특성의 합은 1을 초과할 수 없다.
Disable 이 타임라인을 디스에이블시켜, 타이밍 트리로부터 이 타임라인을 효과적으로 제거한다.
Duration 시작에서 끝까지의 단일 기간의 지속기간이다.
Enable 이 타임라인을 인에이블시켜, 이 타임라인을 타이 밍 트리에 효과적으로 삽입한다. 이 메소드는 이 타임라인이 자동 부모화 타임라인이고, 디폴트 부 모가 지정되지 않은 경우에는 효과를 갖지 않는다.
End 이 타임라인의 최대 종료 시간. 이 값이 시작 및 지속기간 속성들의 합보다 작은 경우, 활성 기간이 이 특성만큼 짧아진다. 또한, 이 특성에 의해 지 정된 시간을 지난 모든 시작(스케쥴링되거나 상호 작용된)은 무시된다.
EndIn 미래 또는 과거의 지정된 시점에서 상호작용 종료 를 트리거한다. 이 파라미터는 이 타임라인의 부 모 타임라인의 기준 프레임 내에 있다. 부모 타임 라인이 활성이 아닌 경우, 이 메소드는 어떠한 효 과도 갖지 않는다.
EndSync 이 특성은 타임라인의 암시적인 지속기간을 정의하 는 데 사용되는데, 지속기간 특성이 명시적으로 설 정되지 않은 경우에 사용된다. 타임라인의 암시적 지속기간은 그 타임라인이 제어하는 타이밍된 객체 에 의해, 또는 그 타임라인의 자식이 될 수 있는 다른 타임라인들에 의해 정의될 수 있다.
Fill 종료 시간 경과 후의 타임라인의 행동. 디폴트로, 타임라인은 시작에서 끝까지 단지 "온" 상태이나, 이 특성이 "고정(freeze)"으로 설정되는 경우, 타 임라인은 종료 시간을 지나서도 온으로 유지된다. 이 경우, 종료 시간 후의 진행 값은 종료 시간에서 의 값과 항상 동일하다. 가능한 값으로는 Remove( 글로벌 디폴트), Freeze, Hold, Transition 및 Auto가 있다.
FillDefault Fill 특성의 디폴트 값. Fill 특성이 지정되지 않 은 경우, 이 특성은 Fill 행동을 결정하는 데 사용 된다. 또한, 이 디폴트는 자식 타임라인들이 그 자신의 FillDefault 특성 세트를 갖지 않는 경우 자식 타임라인들에 의해 상속된다. 가능한 값은 Fill 특성과 동일하다.
IsChanging 타임라인이 활성이면 참, 그렇지 않으면 거짓.
IsEnabled 타임라인이 타이밍 서브 트리의 일부이면 참, 그렇 지 않으면 거짓이다. 이 속성이 참인 경우, 이것 은 이 타임라인이 그의 일부인 서브 트리 자체가 인에이블되는 것을 보장하지 않는다.
IsForwardProgressing 벽시계 시간에 비해, 이 타임라인에서의 진행이 0 에서 1로 이동하면 참이다. 이 속성은 잠재적으로 역행하는 타임라인들 내에 중첩되는 효과를 고려한 다. IsOverrinngBaseValue가 거짓이면, 이 속성은 이 타임라인의 부모 타임라인이 리턴하는 것과 동 일한 값을 리턴한다.
IsOverridingBaseValue 타임라인이 활성이거나 Fill 기간에 있으면 참.
IsPaused 타임라인이 활성이지만 중지 상태에 있으면 참.
IsReversed 타임라인 자신에 로컬한 기준 프레임에서 볼 때, 타임라인이 역행 기간에 있으면 참이다. 이 속성 은 잠재적으로 역행하는 타임라인들 내에 중첩되는 효과를 고려하지 않는다. IsOverridingBaseValue 가 거짓인 경우, 이 속성은 거짓을 리턴한다.
ParentTimeline 이 타임라인의 타이밍 부모인 타임라인이다. 이 것은 임의의 다른 타임라인 또는 2개의 특수 기준 값 중 하나, 즉 Timeline.VisualParent 또는 Timeline.RootTimeline에 대한 기준일 수 있다. 이 속성이 Timeline.VisualParent로 설정되는 경 우, 이 타임라인은 사용시에 이 타임라인이 사용되 는 비주얼과 연관된 타임라인에 대해 자동-부모화 된다(비주얼이 연관된 DefaultTimeline을 갖지 않 는 경우, 부모 비주얼은 반복적으로 검사된다). 이 속성이 Timeline.RootTimeline으로 설정되는 경 우, 이 타임라인은 사용시에 타이밍 트리의 루트에 대해 자동-부모화 된다.
Pause 이 타임라인 및 그의 자식 타임라인들 모두를 중지 한다. 이 타임라인이 활성인 경우, 이 메소드는 어떠한 효과도 갖지 않는다.
Paused 타임라인에 의해 이 타임라인 또는 그의 후손들 중 하나가 중지될 때마다 발생한다.
Progress 타임라인의 현재 진행 값. IsOverridingBaseValue 가 거짓인 경우, 이 속성은 0을 리턴한다. 모든 경우에, 이 속성의 리턴 값은 항상 0 내지 1이다.
RepeatCount 시작 및 종료 기간이 반복되어야하는 회수. 이것 은 타임라인이 영원히 반복되어야하는 것을 나타내 는 특수 값 float.PositiveInfinity는 물론 분수 값일 수 있다. 이 특성 및 RepeatDuration 특성 양자가 지정되는 경우, 총 활성 지속기간은 이 둘 의 최소값이다.
RepeatDuration 시작에서 종료 기간이 반복되어야하는 시간 길이이 다. 이것은 분수 반복 회수이거나, 타임라인이 영 원히 반복되어야 하는 것을 나타내는 특수 값 Time.Indefinite일 수 있다. 이 특성 및 RepeatCount 특성 양자가 지정되는 경우, 총 활성 지속기간은 이 둘의 최소값이다.
Repeated 타임라인에 의해, 이 타임라인이 그의 단순 지속기 간을 반복할 때마다 발생한다.
Restart 제2(또는 이후) 시작 시간이 반복될 때의 타임라인 의 행동. 디폴트로, 시작 시간은 임의의 활성 기 간을 인터럽트하며, 타임라인에 대해 시간 t=0으로 돌아가지만, 이 특성이 WhenNotActive로 설정되는 경우, 활성 기간을 인터럽트하는 시작 시간은 무시 된다. 가능한 값은 Always, WhenNotActive 및 Never이다.
RestartDefault Restart 특성의 디폴트 값. Restart 특성이 지정 되지 않은 경우, 이 특성은 재시작 행동을 결정하 는 데 사용된다. 또한, 이 디폴트는 그 자식 타임 라인들이 그들 자신의 RestartDefault 특성 세트를 갖지 않는 한 그에 대해 부모화된 타임라인들에 의 해 상속된다. 가능한 값들은 Restart 특성과 동일 하다.
Resume 이 타임라인 및 그 자식 타임라인들 모두를 재개한 다. 이 타임라인이 활성이 아니고 중지되면, 이 메소드는 어떠한 효과도 갖지 않는다.
Resumed 타임라인에 의해, 타임라인이 재개될 때마다 발생.
Reversed 시간 방향이 변경될 때마다 타임라인에 의해 발생
Seek 이 타임라인의 현재 시간을 변경하는데, 이는 그 자식 타임라인들 모두에 효과를 줄 수 있다. 이 타임라인이 활성이 아닌 경우, 이 메소드는 어떠한 효과도 갖지 않는다.
Seeked 타임라인에 의해, 그의 시간이 Seek 연산의 결과로 서 변경될 때마다 발생한다.
Speed 시간이 이 타임라인에 대해 경과해야 하는, 그의 부모 타임라인에 비교한 상대 속도. 예를 들어, 1 의 값은 정상 속도를 의미하는 반면, 2의 값은 시 간이 빠르게 두 번 경과하는 것을 의미한다(따라 서, 인식되는 지속기간은 지속기간 특성에 의해 지 정되는 것의 절반만에 종료한다). 이 값은 음일 수 있는데, 이 경우에 부모 타임라인이 역행한 것 처럼, 이 타임라인에서 시간은 종료 시간에서 시작 시간으로 뒤로 흐른다.
그래픽 장면은 소정의 렌더링 연산들에 애니메이트된 파라미터들을 지정하거나 소정의 요소 특성들에 애니메이션들을 추가함으로써 애니메이트될 수 있다. 애니메이션은 소정의 임의의 입력 세트(이들 중 적어도 하나는 일반적으로 타임라인이다)를 취하고 렌더링 연산으로 전달될 올바른 타입의 출력을 생성하는 함수이다. 예를 들어, PointAnimation은 타임라인 진행 값을 Point 값 타입으로 변환한다. 동시에, 하나 이상의 Point 값을 파라미터로 취하는 다양한 렌더링 연산들도 Point 대신에 PointAnimation을 수신할 수 있는데, 이 경우에 애니메이션 함수는 각각의 프레임에서 평가되어 그 프레임에서 사용하는 Point를 계산한다.
애니메이션들은 컬렉션(collection)들로 그룹화된다. 애니메이션 컬렉션은 파이프라인으로서 동작하며, 속성의 기본 값을 입력으로서 취하여 그 속성에 사용되어야하는 현재 값을 출력으로서 생성한다. 그 컬렉션은 0개 이상의 애니메이션 객체를 연결하는데, 각각의 객체는 입력 값을 취하여 동일한 타입의 출력을 생성하는 유사한 시맨틱을 지원한다. 파이프라인은 규칙적인 간격으로 평가되며, 그 출력은 렌더링 연산에 사용되어 애니메이션의 효과를 생성한다.
애니메이트될 수 있는 값들은 다양한 타입을 가지므로, 다양한 상이한 타입의 애니메이션들이 또한 존재한다. 그러나, 모든 애니메이션은 공통 패턴을 따르며, 한 세트의 공통 인터페이스를 구현한다. 애니메이션 객체들은 3 그룹의 클래 스, 즉 수정자, 타이밍된 수정자 및 애니메이션으로 체계화된다.
간단한 애니메이션은 시점과 종점 사이에 값을 보간한다. 시점 및 종점 양자가 지정될 때, 기본 값은 애니메이션이 "온" 상태인 시간 동안 무시된다. 애니메이션이 "오프" 상태일 때, 그 속성의 값은 기본 값으로 복귀한다. 애니메이션은 그의 관련 타임라인이 "온" 상태인 한은 "온" 상태라는 점에 유의한다. 따라서, 프롬-투(from-to) 애니메이션은 Fill 타이밍 특성을 "고정"으로 설정함으로써 기본 값을 항상 무시하도록 만들어질 수 있다. 도 36은 From=10 및 To=70으로 y에서 애니메이트된 점을 나타낸다.
둘 다가 아니라 시점 또는 종점만이 지정되는 경우, 속성의 기본 값은 다른 점의 값에 사용된다. 이것은 이전의 예와 중복되는 것처럼 보이지만, 이 경우에는 기본 값이 무시되지 않고 애니메이션으로 구성된다는 점에 중요한 차이가 있다. 이것은 기본 값이 변경되고 있거나 애니메이션이 다른 애니메이션에 연결되어 있는 경우에 흥미로운 결과를 낳는다.
애니메이션 함수를 지정하는 또 하나의 방법은 기본 값으로부터 델타를 지정하는 것이다. 이것은 기본 값에서 기본 값+델타로 보간하는 프롬-투 애니메이션과 개념적으로 유사하다. 그러나, 이 경우에는 시점 및 종점 양자가 기본 값으로 합성된다.
애니메이션과 관련된 타임라인이 반복하도록 설정되는 경우, 애니메이션은 시작에서 끝으로 여러번 실행된다. 도 37은 From=10, By=60 및 RepeatCount=2로 y에서 애니메이트된 점을 나타낸다. 반복마다 동일 궤도를 반복하는 대신에, 애니 메이션은 각각의 반복의 결과를 축적하여 본질적으로 그 자체를 구성하도록 프로그래밍될 수 있다. 도 38은 From=10, By=60, RepeatCount=2 및 IsAnimation=True로 y에서 애니메이트된 점을 나타낸다.
프롬-투 애니메이션의 디폴트 행동이 애니메이트된 속성의 기본 값을 무시하지만, 이 행동은 시작 값과 종료 값 양자가 기본 값으로부터의 델타인 추가 행동으로 변경될 수 있다.
다음 도표는 기본 애니메이션 타입들을 요약한 것이다.
타입 출력 값
From t=0에서의 "From" 값 및 t=1에서의 기본 값
To t=0에서의 기본값 및 t=1에서의 "To" 값
From-To t=0에서의 "From" 값 및 t=1에서의 "To" 값
By t=0에서의 기본 값 및 기본 값과 t=1에서의 "By" 값의 합
From-By t=0에서의 "From" 값 및 t=1에서의 "From" 및 "To" 값들의 합
기본 애니메이션에서, 시점 및 종점에서의 출력 값은 지정되며, 이들 사이의 값들을 계산하기 위해 선형 보간이 이용된다. 보다 복잡한 애니메이션 함수들에 대해서는 값들의 리스트가 대신 지정될 수 있다. 각각의 값은 키 프레임에 대응한다. 간단한 경우, 이 키 프레임들은 규칙적인 간격으로 발생한다. 애니메이션들은 또한 키 프레임들 사이에 조정된(paced) 간격을 사용하도록 프로그래밍될 수 있다. 조정된 보간 방법에서, 키 프레임들의 각 쌍 사이의 공간은 두 키 값들 사이 의 간격과 애니메이션에 의해 커버되는 총 간격의 비에 비례한다. 이것은 예를 들어 부동 또는 점 애니메이션들과 같은 간격의 의미있는 개념을 갖는 타입의 애니메이션들에 대해 가능하다. 이 경우, 키 프레임들 사이의 보간은 선형이다. 세번째 옵션은 전혀 보간을 행하지 않는 것이데, 이 경우 출력 값 함수는 이산적이다. 도 39는 KeyValues=10,90,70 및 다양한 보간 방법들로 y에서 애니메이트된 점을 나타낸다.
추가적인 제어를 위해, 각각의 키 프레임에 대한 시간은 명시적으로 지정될 수 있다. 키 프레임들 사이의 보간은 선형이거나 이산적일 수 있다. 키 시간들은 총 애니메이션 지속기간의 퍼센트로서 지정되며, 전 기간을 커버해야 한다. 즉, 제1 키 시간은 0이고, 선형 보간에 대해 최종 키 시간은 1이다. 도 40은 KeyValues=10,90,50 및 KeyTimes=0,.2,1로 y에서 애니메이트된 점을 나타낸다.
보간에 대한 보다 추가적인 제어를 위해, 한 세트의 3차 비지어 곡선들이 애니메이션에 사용되는 시간 곡선을 설명하기 위해 사용될 수 있다. 이것은 스크린 상에 렌더링되는 비지어 곡선과 혼동되지 말아야 하는데, 이 곡선은 타이밍 곡선의 모양을 수정하는 데 사용되지만, 키 프레임 값들은 여전히 진행 값에 대해 선형으로 보간한다. 이러한 스플라인 보간 방법은 애니메이션과 관련된 타임라인에 의해 제공되는 선형 0-1 진행 값을 비선형 0-1 진행 곡선으로 변환하는 필터를 추가한다.
다음 도표는 애니메이션 특정 특성들 및 그들의 의미의 리스트를 포함한다. 이 리스트는 모든 애니메이션 객체들이 따르는 템플릿이다. 특성의 타입이 "<ValueType>"인 경우, 실제 객체는 애니메이션 타입과 매칭되는 타입을 가진 특성을 노출시킨다. 예를 들어, ColorAnimation 객체는 이들의 특성을 "Color" 타입으로 만든다. 아래에 열거된 특성들 외에, 애니메이션 객체들은 ITimingAttributes 인터페이스에서 지정되는 특성들을 지원한다.
| 특성 | 타입 | 의미 |
| By | <ValueType> | 애니메이션의 종료시의 델타값. 시작에서의 값은 지정된 경우에는 From 값이거나 속성의 기본 값이다. |
| From | <ValueType> | 애니메이션의 초기 값 |
| InterpolationMethod | InterpolationMethod | 키 값들 사이에 보간하는 데 사용되는 메소드. 가능한 값들은 Discrete, Linear, Paced 또는 Spline이다. |
| KeySplines | KeySplineCollection | 애니메이션의 간격 조정(pacing)을 제어하는 3차 함수를 정의하는 KeyTimes 리스트와 관련된 한 세트의 비지어 제어 점들. 이 리스트는 KeyTimes 리스트보다 하나 적은 요소를 포함해야 한다. 이 리스트는 InterpolationMethod 특성이 Spline로 설정된 경우에만 사용된다. |
| KeyTimes | KeyTimeCollection | 애니메이션의 조정을 제어하는 데 사용되는 시간 값들의 리스트. 이 리스트는 KeyValues 리스트와 동일한 수의 요소를 포함해야 한다. 이 리스트는 증가하는 시간 값들로 정렬되며, InterpolationMethod가 Discrete로 설정되지 않은 경우, 이 리스트의 최초 값은 0이어야 하고 최종 값은 1이어야 하는데, 이 경우에 최종 값은 1 이하일 수 있다. |
| KeyValues | <ValueType>KeyValueCollection | 애니메이션에 대한 값들의 리스트 |
| To | <ValueType> | 애니메이션의 종료시의 값 |
Animatable 클래스는 Changeable 클래스로부터 도출된다. 이것은 매체 자원과 같이 애니메이트되거나 애니메이트된 값들을 포함할 수 있는 임의의 객체 또는 객체 컬렉션에 의해 기본 클래스로 사용된다. Modifiers, TimeModifiers 및 Animations는 아이러니하게도 Animatable 대신에 Changeable로부터 도출되는데, 이는 이들의 개별 속성들이 애니메이트 가능하지 않기 때문이다.
| 메소드, 속성 또는 이벤트 | 의미 |
| HasAnimations | 객체가 시간에 따라 변하는 경우 참이다. 일반적으로, 이 속성은 객체가 임의의 애니메이션 컬렉션들에 유지되고 있는 경우 참이다. |
| IsAnimating | 객체 내의 애니메이션들 중 어느 하나가 변경되고 있는 경우 참이다(Modifier.IsChanging 참조) |
| IsOverridingBaseValue | 객체 내의 애니메이션들 중 어느 하나가 변경되거나 Fill 상태에 있음으로써 현재 활성이고 객체를 수정하고 있는 경우 참이다. |
| GetCurrentValue | 이 객체의 순간 값과 동일한 값을 갖지마나 시간에 따라 변하지 않는 객체를 리턴한다. DoesChange 속성이 거짓인 경우, CurrentValue 속성은 새로운 사본이 아니라 객체 자체를 리턴할 수 있다. |
| SetDefaultParentTimeline | 임의 자동 부모화된 타임라인들의 부모인 타임라인. 이 속성이 설정되는 경우, 임의의 자동 부모화 타임라인들은 다시 자식이 되지만, 이 타임라인들에 대해 또는 이 객체에 대해 새로운 사본은 생성되지 않는다. |
Modifier 클래스들, 따라서 TimeModifiers 및 Animations은 Animatable 대신에 Changeable로부터 도출되는데, 이는 이들의 개별 속성들이 애니메이트되어서는 안 되기 때문이다. 이것은 프로그래머들이 애니메이션 상에 From 속성을 애니메이트 할 수는 없어야 한다는 사실을 강화한다.
Modifier 클래스들은 Unchangeable의 StatusOfNextUse 속성 값을 가질 수 없다. Modifiers의 StatusOfNextUse에 대한 디폴트 값은 ChangeableCopy이지만, 사용자가 Modifier를 재사용하기를 원할 경우 ChangeableReference로 설정될 수도 있다. 사용자가 StatusOfNextUse를 ChangeableReference로 설정하는 경우, 임의의 첨부된 Modifier가 ParentTimeline 속성 세트를 갖지 않는 경우에는 예외가 발생한다. 이것은 충돌하는 상속된 부모 타임라인들을 갖는 상황을 방지한다. Animatable의 애니메이트되지 않고 변경되지 않은 브랜치들(branches)은 Unchangeable의 StatusOfNextUse 값을 가질 수 있으며, 사용시 변경 불가능하게 될 수 있다. From, To 또는 By와 같은 Modifier 클래스 상의 속성들은 그 Modifier의 수명 동안 변경가능으로 유지된다.
Modifier들은 그들의 수명 동안 변경가능하며, 따라서 MakeUnchangeable은 이들 클래스 상에 예외를 발생시킨다. 현재 애니메이션을 포함하고 있는 Animatable에 대해, MakeUnchangeable은 예외를 발생시킨다.
사용자가 Animatable 클래스 상의 변경된 통지에 대해 서명하는 경우, 사용자는 속성 변경에 의해 또는 애니메이션의 속성을 통해 발생된 변경에 대한 통지를 수신한다. 즉, 사용자는 Animatable에 의해 사용되는 애니메이션들과 관련된 타임라인들이 이들이 제공되는 각각의 프레임 상에 있음에 따라 탐색되거나 앞으로 이동할 때 변경된 통지를 수신한다.
독립적으로 애니메이트된 속성들(예를 들어 불투명도) 또는 Animatable들(예를 들어 SolidColorBrush)의 경우, 핸들러를 제공한 임의의 사용자에게 전송된 Changed 통지는 합성기 프레임 속도(compositor frame rate)가 아니라 UI 스레드 프레임 속도로 발생한다. 이 경우 애니메이션의 정확한 값은 스크린 상에 있는 값들에 가까워야 하지만 정확하게 그 스크린 상에 있는 값인 것이 보장되지는 않는다.
애니메이션이 종속적 또는 MIL 종속적인 경우, 어느 통지가 렌더링 전달에 대응하는지, 따라서 어느 것이 표시될 값을 반사하는지를 현재 알 수는 없지만 스크린 상에 있을 값과 매칭되는 값을 취득할 수 있다. 종종 발생할 수 있는 바와 같이, 타이밍 트리가 렌더링 전달 동안 변경되는 경우, 사용자가 다수의 통지를 수신하는 것이 가능하며, 따라서 사용자는 어느 것이 스크린 상의 결과적인 값에 대응하는지를 알 가능성이 적다.
수정자는 소정 타입의 "기본 값"이라고 하는 객체를 입력으로 취하고 동일 타입의 다른 객체를 입력으로 리턴하는 GetValue 메소드를 구현하는 객체이다. 출력의 값은 입력 및 수정자의 내부 상태 양자에 의존한다. 특히, 이것은 동일 입력으로 두번 이상 GetValue를 호출하는 것은 동일 출력을 리턴하는 것이 보장되지 않는다는 것을 의미한다. 그래픽 애니메이션은 수정자의 GetValue 메소드가 프레임당 한번 호출되어 각 프레임에 대해 새로운 값을 생성할 때 발생한다.
일반적인 경우, GetValue 메소드의 리턴 값에 대한 보장이 없으며, 메소드가 호출될 때마다 메소드는 다른 값을 리턴할 수 있다. 수정자들을 소비하는 객체들 은 이것이 그 경우임을 가정하고 다음 예에서와 같이 수정자를 반복 호출할 수 있다.
그러나, 실제로는 수정자가 그의 내부 상태에 따라 동일한 입력이 주어질 때 동일한 출력을 생성할 것으로 예측하는 시간들이 있을 수 있다. 수정자는 GetValue의 리턴 값이 각각의 호출시에 다를 수 있는 기간에 있을 때 변경되고 있다고 말한다. GetValue의 리턴 값이 각각의 호출시에 동일한 때 수정자는 변경되고 있지 않다. 수정자가 변경되고 있지 않을 때, 그 수정자의 사용자는 GetValue 메소드의 리턴 값을 안전하게 캐싱할 수 있으며, 아마도 다음 예에서와 같이, GetValue 메소드를 반복적으로 불필요하게 평가하는 것을 피할 수 있다.
추상 수정자 클래스가 구현되며, 그로부터 수정자들이 상속해야 한다. 이 클래스는 GetValue 및 GetUniqueInstance 메소드들을 제외한 모두에 대한 디폴트 구현을 제공한다.
다음 도표는 수정자 클래스의 시맨틱들을 요약한 것이다.
| 메소드, 속성 또는 이벤트 | 의미 |
| Changed | 수정자에 의해, 그의 내부 상태가 변경될 때마다 발생한다. |
| ParentTimeline | 이 수정자 내의 자동 부모화 타임라인들의 부모인 타임라인. 이 속성이 설정되는 경우, 이 수정자 내의 임의의 자동 부모화 타임라인들은 다시 새로운 부모 타임라인에 대하여 재부모화 된다. |
| GetUniqueInstance | 다른 인스턴스들과 별개로 그 자신의 실행시간 상태를 유지할 수 있는 이 수정자의 인스턴스를 리턴한다. 이 수정자가 자동 부모화 타임라인들을 포함하는 경우, 리턴되는 인스턴스는 파라미터로서 전달되는 타임라인에 대해 부모화된 타임라인들을 갖는다. |
| GetValue | 독립변수로서 전달되는 기본 값 및 수정자의 내부 상태에 기초하여 이 수정자의 현재 출력 값을 계산한다. IsOverridingBaseValue 속성이 거짓인 경우, 이 함수는 기본 값을 리턴하는 것이 보장된다. |
| IsChanging | 수정자가 현재 변경되고 있는 경우 참이고, 수정자가 변경되지 않는 기간에 있는 경우 거짓이다. 이 플래그는 ChangeBugun 및 ChangeEnded 이벤트들과 함께 최상으로 사용된다. 이 플래그가 참이면, IsOverridingBaseValue도 참이어야 한다. |
| IsOverridingBaseValue | GetValue 메소드의 리턴 값이 현재 수정자에 의해 영향을 받고 있으면 참이다. 이 값이 거짓일 때, GetValue는 독립변수로서 그것에 전달되는 동일 객체를 리턴하는 것이 보장된다. 수정자는 기본 값을 무시할 수 있지만 변경될 수는 없다. |
| UsesBaseValue | GetValue의 리턴 값이 기본 값에 의존하면 참이다. 이 속성이 거짓이면, 이는 수정자가 기본 값을 완전히 무시한다는 것을 의미한다. 수정자가 리스트 내에 있는 경우, 이 속성은 수정자들의 서브세트만이 소정의 경우에 평가되어야 하는 최적화를 허용한다. |
또한, 수정자로부터 상속되지만 인터페이스 메소드들의 타입-안전 버전들을 노출시키는 한 세트의 타입 특정 클래스들이 구현된다. 다음 예는 FloatModifier 클래스를 나타낸다.
타이밍된 수정자는 적어도 부분적으로 Timeline 객체에 의해 제어되는 행동을 갖는 수정자이다. 전술한 수정자 규칙들이 적용되지만, 또한 타이밍된 수정자는 수정자의 타임라인의 제어를 노출시키는 ITimingControl 인터페이스를 구현한다. 추상 TimeModifier 클래스는 존재하지 않는다. 대신에, 타입 특정 클래스들은 타입 특정 수정자 클래스들로부터 상속된다. 다음 예는 FloatTimeModifier 클래스를 나타낸다.
Modifier 및 ITimingControl 인터페이스는 소정의 유사한 메소드, 속성 및 이벤트를 갖는다는 점에 유의한다. 타이밍된 수정자는 그들에 대한 단일 구현을 노출시킨다. 타이밍된 수정자는 그렇게 할 필요는 없지만 모든 호출을 제어 타임라인으로 전송함으로써 ITimingControl을 자유롭게 구현한다. 타입 특정 타이밍된 수정자 구현들에 의해 제공되는 ITimingControl의 디폴트 구현은 호출들을 제어 타임라인으로 전송한다.
애니메이션은 특정 애니메이션 함수를 구현하는 타이밍된 수정자이다.
애니메이션 컬렉션은 애니메이션 객체들(<Type>Modifier로부터 상속)의 리스트인데, 여기서 예를들어 제1 객체로부터의 GetValue 메소드의 출력은 제2 객체 상의 GetValue 메소드에 대한 기본 값 파라미터로서 사용된다. 유연성을 위해, 애니메이션 컬렉션에 포함된 객체들은 실제로 타입 특정 수정자 타입이다. 컬렉션 전체는 IModifier.GetValue와 같이 보이는 GetValue 메소드를 지원한다. 사실, 애니메이션 컬렉션들은 IModifier 인터페이스의 대부분을 지원하지만, 이들은 실제로 IModifier를 구현하지 않는데, 이는 이들이 "UsesBaseValue" 속성(이 속성은 항상 컬렉션 전체에 대해 참인 것으로 가정된다)을 지원하지 않기 때문이다.
애니메이션 컬렉션들로부터 시작된 이벤트들은 합체(coalesce)된다.
경로 애니메이션들은 TimedMatrixModifier 클래스의 특수화이다. MatrixModifier는 MatrixTransform과 함께 사용될 수 있다. MatrixTransform은 Matrix 속성, 및 MatrixAnimations 속성을 가지며, PathAnimation은 MatrixModifier이므로, MatrixAnimation으로서 사용될 수 있다.
| 메소드, 속성 또는 이벤트 | 의미 |
| Geometry | 이것은 임의의 형상일 수 있다. 타원에 대해, 진행 0에 대한 적절한 시작점이 선택된다. 형상이 많은 부 형상을 갖는 경우, 이들의 경로들 각각은 이들이 형상 내에 정의된 순서로 번갈아 이동한다. |
| DoesRotateWithTangent | 이 속성이 거짓으로 설정되는 경우, 객체는 회전 없이 형상 경로를 따라 이동한다. 참으로 설정되는 경우, 객체는 임의의 주어진 위치에서 경로의 탄젠트에 매칭되도록 회전한다. |
마크업 사용:
애니메이트될 수 있는 모든 자원, 메소드 또는 객체는 이것이 Animatable 인 터페이스를 구현하는 것을 포함하는 다수의 규칙을 따른다. "Bar" 타입의 "Foo"라고 하는 모든 애니메이트 가능한 속성(또는 파라미터)에 대해, "BarAnimationCollection" 타입의 "FooAnimations"라고 하는 또 하나의 속성(또는 파라미터)이 존재한다. 애니메이션이 원해지는 어느 경우에도, 애니메이션 컬렉션들이 사용된다. 기본 수정자 또는 애니메이션 객체들은 이들이 애니메이션 구성을 배제(preclude)하기 때문에 직접 사용되지 않는다.
자원들은 개별 속성들에 애니메이션 컬렉션들을 추가함으로써 애니메이트될 수 있다. 다음 예는 애니메이트 칼라를 가진 SolidColorBrush를 어떻게 생성하는지를 나타낸다.
애니메이트 자원들은 렌더링 연산에서 또는 요소 속성들에 대한 값으로서 사용될 수 있다.
렌더링 연산은 드로잉 컨텍스트 메소드 호출에 애니메이션 컬렉션을 추가하거나 애니메이트 자원을 사용함으로써 애니메이트될 수 있다. 다음 예는 애니메이 트된 불투명 값이 어떻게 드로잉 컨텍스트 내에 푸시되는지를 나타낸다.
요소들은 요소 속성들에 애니메이션 컬렉션을 추가함으로써 애니메이트될 수 있다. 다음 예는 C#에서 버튼의 폭을 어떻게 애니메이트하는지를 나타낸다.
다음은 XAML에서의 동일 예를 나타낸다.
애니메이션(또는 애니메이트된 자원)이 사용될 때마다, 애니메이션(또는 자원)은 목적지에 고유한, 독립적으로 제어가능한 타임라인을 제공하기 위해 (얕고 효율적인 방법으로) 복제된다. 이 행동의 부작용은 오리지날 애니메이션이 비주얼 장면의 일부가 아니며, 따라서 ITimingControl 인터페이스를 통한 제어 호출에 응답하지 않는다는 것이다. 이 효과를 달성하기 위하여, 호출 코드는 먼저 애니메이션을 이용한 후 애니메이션을 판독한다. 이어서, 판독된 값은 캐싱되고 타이밍 제어에 사용될 수 있다. 다음 예는 애니메이션을 제어하기 위한 코드가 따를 수 있는 패턴을 나타낸다.
사용자는 AnimationEffect를 구현하기 위해 AnimationEffect를 기본 클래스 로 사용하여 새로운 클래스를 생성한다. 사용자는 또한 그들의 AnimationEffect에 대한 빌더(builder)를 생성해야 한다.
| 메소드, 속성 또는 이벤트 | 의미 |
| Invalidate | 사용자는 이들이 AnimationEffects의 리스트 내에 있는 이들의 AnimationEffect가 다음 RenderQueueItem 동안 처리되기를 원하고 RenderQueueItem이 스케쥴링되는 것을 확실히 하기를 원할 때 이를 호출한다. 무효 애니메이션들의 리스트는 RenderQueueItem의 시작에서 리셋된다. |
| InvalidatePassive | 사용자는 이들이 AnimationEffects의 리스트 내에 있는 이들의 AnimationEffect가 다음 RenderQueueItem 동안 처리되기를 원하지만, RenderQueueItem이 스케쥴링되는 것을 원하지 않을 때 이를 호출한다. |
| IsInvalid | 애니메이션이 현재 다음 RenderQueueItem 동안 처리될 AnimationEffects의 리스트 내에 있는 경우 참을 리턴한다. 이것은 Invalidate가 호출되었으므로 참일 수 있다. |
| Element | 이것은 AnimationEffect가 첨부되는 요소이다. AnimationEffect가 요소에 첨부되면, 이것은 예외를 발생시킨다. 사용자는 OnAttach가 호출될 때까지 어떠한 셋업도 행하지 말아야 한다. |
| AttachImpl | AnimationEffect가 요소에 첨부될 때, 이것은 자동 복제되며, 새로운 복제본은 요소 상의 AnimationEffects의 컬렉션에 추가되고, OnAttach를 호출한다. 이때, AnimationEffect 상의 보호된 요소 속성이 설정된다. 사용자가 컬렉션에 AnimationEffect를 추가한 경우, 새로운 AnimationEffect만이 OnAttach를 호출한다. OnAttach가 호출될 때 요소가 그의 마크업 속성 세트를 가질 것이라거나 요소의 자식들이 모두 적소에 있을 것이라는 보장은 없다. AnimationEffect가 복제된다. 요소는 모든 함수를 호출할 때 AnimationEffect로 전달될 수 있지만, AnimationEffect가 그것을 가장 필요로 하는 경우일 것인 다른 요소들로부터의 이벤트에 대한 이벤트 핸들러로 전달될 수 없다. AnimationEffect는 다른 요소들 상에 이벤트 핸들러를 셋업할 수 있지만, 여전히 이 요소에 할당된다는 것을 알 필요가 있다. |
| DetachImpl | 이것은 요소로부터 분리될 때 AnimationEffect 상에 호출된다. |
| PreLayoutReadImpl | 이것은 RenderQueueItem 내의 레이아웃을 실행하기 전에 오염된 경우 AnimationEffect 상에 호출된다. 이것은 AnimationEffect가 필요로 하는 값을 판독해야 하는 시간이다. 판독 및 기록이 분리되는 이유는 판독은 레이아웃이 즉시 실행되기 하고, 모든 AnimationEffect가 번갈아 판독하고 기록하는 경우 전체 프로세스를 느리게 하기 때문이다. |
| PreLayoutWriteImpl | 이것은 RenderQueueItem 내의 레이아웃을 실행하기 전에 오염된 경우 AnimationEffect 상에 호출된다. AnimationEffect가 처리되는 순서를 보장하지 못하지만, 모든 오염된 AnimationEffect는 호출되기 전에 OnPreLayoutRead를 호출했을 것이라는 것을 보장한다. |
| PostLayoutReadImpl | 이것은 RenderQueueItem 내의 레이아웃을 실행한 후에 오염된 경우 AnimationEffect 상에 호출된다. IsAlwaysDirty 플래그가 설정되지 않은 경우, 이 AnimationEffect 상의 오염된 플래그는 거짓으로 설정되었을 것이며, 다음 RenderQueueItem 동안 처리될 AnimationEffects의 리스트로부터 제거되었을 것이다. AnimationEffect가 이 메소드 내의 SetDirty를 호출하는 경우, 다음 RenderQueueItem 동안의 처리를 위해 이것을 효과적으로 오염된 채로 유지할 것이다. AnimationEffect가 오염된 채로 유지되기를 원하는 경우, IsAlwaysDirty 플래그를 설정하는 것이 보다 효율적이다. |
원시함수(Primitive) 타입들
MIL에서의 기본 길이 단위는 더블이며, 이에 따라 다른 원시함수 타입들 및 API들은 더블에 기초한다. 일반적으로, 이러한 더블들은 초기에 1인치의 1/96번째와 같은 사용자 단위로서 평가된다. 칼라에 대해, 칼라 채널들 각각은 더블이 아니라 부동(float)으로 표현된다. 각도 측정에 대해, 더블 값들의 단위는 도(degree)이다. 부동 또는 더블이 시간 측정치로서 평가될 때, 이것은 초로 가정된다.
시간 구조는 특정 시점 또는 시간의 길이(span)를 나타낸다. 또한, "Indefinite"라고 하는 특수 시간 값은 미래의 무한 시점 또는 무한히 긴 시간 길이를 나타낸다. 시간값들은 속성 시스템에서 사용되도록 설계되며, 따라서 "Unspecified"라고 하는 특수 값은 속성을 소거하거나 속성이 설정되지 않았음을 명시적으로 나타내는 데 사용될 수 있다. 시간 값들은 정수 카운트로서 내부적으로 저장된다.
위의 문법 외에, "분" 및 "초"는 유효한 것으로 간주되는 "00" 내지 "59"의 범위로 지정되어야 한다. 또한, "시간 카운트 값" 포맷이 단위 없이 사용되는 경우, 이 값은 초인 것으로 가정된다. 다음은 시간 값 및 그 의미에 대한 몇몇 예이다.
시간 값
02:30:03 2시간 30분 3초
50:00:10.25 50시간 10초 250밀리초
02:33 2분 33초
00:10.5 10초 500밀리초
3.2h 3시간 12분
45min 45분
30s 30초
5.45ms 5.45 밀리초
12.467 12초 467밀리초
1d 1일
시간 구조는 단일 시간 값을 저장하는 데 사용된다.
다른 기본 타입들은 아래에 설명되는데, 다음의 기호(notation)가 사용된다.
- *: 0 이상
- +: 1 이상
- ?: 0 또는 1
- {n}: n배
- (): 그룹화(grouping)
- |: 대체물들(alternatives)을 분리함
- 큰 따옴표는 문자들(literals)을 둘러쌈
칼라들에 대한 마크업 신텍스:
칼라 객체는 Red 및 Blue와 같은 여러 공지 칼라를 포함하는 정적 멤버들을 포함한다:
점 구조가 아래에 설명된다.
점 객체에 대한 마크업 신택스:
벡터 객체가 아래에 설명된다:
벡터 객체에 대한 마크업 신택스:
크기는 벡터가 아니며, 따라서 가산, 감산 또는 변환될 수 없다는 점에 유의하자. 또한, 크기는 음(negative)의 폭 또는 높이를 가질 수 없다. 하나를 설정하려는 시도가 행해지는 경우, ArgumentException이 발생한다.
사각형에 관하여, 명칭 Rect는 Rectangle 요소와 충돌하지 않도록 하기 위해 Rectangle 대신 사용된다. 음의 폭 및 높이를 지정하는 것이 가능하지만, 사각형을 정규화하는 표준 방법은 없으며, 사각형에 대한 많은 연산은 직관적이지 않은 결과를 제공할 수 있다. Rect의 폭 및 높이는 음이 아닌 값들로 설정될 수 없다. 이러한 값들이 구축자로 전달되는 경우, 결과는 정규화된다. 폭 또는 높이가 음으로 설정되는 경우, 이것은 ArgumentException을 발생시킨다.
Rect는 그 내부의 점들은 물론 그 에지 상에 위치하는 모든 점들을 포함한다. 따라서, Rect의 에지들이 포함된다. 결과적으로, 0의 폭 또는 0의 높이를 가진 Rect는 Rect에 의해 표현되는 1차원 선분 상에서 발견되는 점들의 집합을 포함하므로 비어 있지 않다. 폭 및 높이가 0인 경우, Rect는 Location에 하나의 Point를 포함한다. 이것은 진정으로 빈 Rect는 특수 값이며, 정적 EmptyRect 속성을 통해 액세스될 수 있다는 것을 의미한다. 빈 Rect의 폭 및 높이 속성은 음의 무한 값(negative infinity)을 리턴하며(어느 하나가 음일 수 있는 유일한 경우), X 및 Y 속성들은 양의 무한 값을 리턴하고, 이들 속성 중 어느 것도 수정가능하지 않다. 이는 "빈(empty)" 폭이 아니라 정상 높이인 것을 보장하거나 그 반대의 경우를 보장한다.
도시된 바와 같이, rect는 다수의 메소드를 제공한다. IsEmpty는 인스턴스가 Empty Rect와 동일한 경우 참을 리턴한다. FromLTRB 메소드는 본질적으로 (좌, 상, 우-좌, 하-상(bottom-top))으로 초기화된 사각형을 리턴한다. Contains 메소드는 Rect가 Empty가 아니고, p.x>=r.x, p.x<=r.x+r.width, p.y>=r.y 및 p.y<=r.y+r.height인 경우 참을 리턴한다. 이것은 이 메소드가 사각형이 음의 폭 또는 높이를 갖는 경우 거짓을 리턴한다는 것을 의미한다.
IntersectsWith는 Rect가 Empty가 아니고, r1.x<=r2.x+r2.width, r2.x<=r1.x+r1.width, r1.y<=r2.y+r2.height, 및 r2.y<=r1.y+r1.height인 경우 참을 리턴한다. 두 사각형의 교차점은 좌 및 상 치수의 최대값 및 우 및 하 치수의 최소값을 취함으로써 계산된다. 어느 하나의 Rect가 Empty인 경우, Empty Rect가 리턴된다.
두 사각형의 합집합은 좌 및 상 치수들의 최소값 및 우 및 하 치수들의 최대값을 취함으로써 계산된다. 어느 하나의 Rect가 Empty인 경우 나머지 Rect가 리턴된다.
Offset 메소드에 대해, 오프셋은 단순히 사각형의 위치에 더해진다. 이 메소드는 Rect가 Empty인 경우 어떠한 효과도 갖지 않는다.
Inflate에 대해, 인플레이션 양은 모든 변에 단순히 동일하게 적용된다. r.x=r.x-s.width; r.y=r.y-s.height; r.width=r.width+2*s.width 및 r.height=r.height+2*s.height를 포함하는 조정이 이루어진다. 이 메소드는 Rect가 Empty인 경우 어떠한 효과도 갖지 않는데, 이는 Empty Rect가 어떠한 위치도 갖지 않기 때문이다.
다음의 마크업 신택스는 x, y, 폭, 및 높이를 지정한다. 이것은 System.Drawing.Rectangle에 대한 타입 변환기(type converter)가 행하는 것과 동일하다는 점에 유의해야 할 것이다.
2D 연산을 위한 행렬들은 3x3 행렬로 표현된다. MIL은 행 벡터 신택스를 사 용한다. MIL은 어파인 변환(affine transform)만을 허용하며, 따라서 완전 3x3 행렬이 아니라 단지 6개의 값만을 필요로 한다. 이들은 아래와 같이 명명되고 정의된다.
행렬이 점과 곱해질 때, 행렬은 그 점을 새로운 좌표 시스템에서 이전 좌표 시스템으로 변환한다.
변환은 임의의 레벨로 중첩될 수 있다. 새로운 변환이 적용될 때마다, 이는 그것을 현재의 변환 행렬 상에 사전 승산(pre-multiplying)하는 것과 동일한다.
API 내의 대부분의 장소는 행렬을 직접 취하지 않는다. 대신, 변환 클래스는 깊은 방식(deep way)으로 애니메이션을 지원한다.
마크업 신택스에 대해, 순서는 M11,M12,M21,M22,OffsetX,OffsetY이다.
3차원 비주얼 및 요소
이 섹션은 사용할 애플리케이션을 위한 매체 통합 계층을 통해 간단한 3차원 효과를 주로 제공하기 위한 3차원 효과에 관련된다. 이러한 효과는 리모팅, 인쇄, 데스크탑 구성과 통합되며, MIL 아키텍처 및 요소 모델, 및 MIL을 통해 매체의 구성 가능성에 명확히 참여한다. 예를 들어, 사업 비주얼화는 3차원 프리젠테이션 및 상호작용성에 대한 몇몇 요건을 갖는다. 이것은 수천 또는 수만개의 객체로의 히트 테스팅 분해(hit tesing resolution)를 요구할 수 있으며, 도 41에 도시된 이미지와 같은 것을 볼 수 있는 상호작용 비주얼화를 유발할 수 있다.
여기 설명되는 기능들은 일반적으로 모델링 툴들을 통해 제공되는 기능이 아니라 실행시간 렌더링 및 상호작용에 관련된다. 제공되는 모델링 기능은 애니메이션 또는 실행시간 구축이 실행시간에 노출되는 것이 필요한 상황을 목표로 한다. 예를 들어, 실제로는 모델링 기능이지만 3D 텍스트 돌출이 제공될 수 있는데, 이는 애플리케이션들이 텍스트를 데이터 결합하기를 원하고, 따라서 이것이 실행시간 기능인 것이 필요하기 때문이다.
전술한 바와 같이, MIL 시스템 내의 비주얼들은 결과적으로 렌더링되는 것의 2D 합성 트리를 표현한다. UiElements 및 Controls는 비주얼들이라는 점에 유의한다. 또한, 비주얼들은 그 비주얼 자체의 콘텐츠의 앞에서(페인터의 알고리즘 용어로) 렌더링되는 자식 비주얼들의 컬렉션을 갖는다. 또한 전술한 바와 같이, RetainedVisual, SurfaceVisual, HwndVisual 등을 포함하는 다양한 구체적인 비주얼 서브 클래스가 존재한다. RetainedVisual은 사용자가 비주얼 상에 직접 생성하거나 레이아웃 시스템으로부터 OnRender() 콜백을 수신한 결과로서 생성하는 한 세트의 2D 드로잉 명령들을 표현한다.
이해되는 바와 같이, 3D는 자연적으로 2D 비주얼 세계에 들어맞는다(fit). 이 때문에, 2D 대응물과 같이 드로잉 컨텍스트를 열고 드로잉 컨텍스트 내에 렌더링함으로써 불가피하게 채워지는 드로잉 명령들의 리스트를 나타내는 Retained3DVisual이 제공된다. 이것은 장면 그래프 또는 메타파일 또는 명령 리스트를 비주얼 자체 내에 효과적으로 구축할 것이다.
Retained3DVisual은 본질적으로 광들(lights), 장면의 2D 프로젝션을 정의하 기 위한 카메라, 프로젝션이 맵핑될 로컬 좌표 공간 내의 사각 2차원 뷰포트(viewport), 및 안티에일리어싱 스위치(antialiasing switches), 포그 스위치(fog switch) 등과 같은 다른 주변 파라미터들을 포함하는 한 세트의 3차원(렌더링 명령 / 장면 그래프 / 메타파일) 데이터이다.
온-디맨드 OnRender() 성능은 Retained3DVisual에 대해서는 제공되지 않는다는 점에 유의한다. 이 기능은 2D 세계에서 드로잉되는 데이터의 양의 관리를 돕기 위해 2D에 대해 존재한다. 2D와 같이, 렌더링은 "즉석 모드 느낌(immediate-mode feeling)" 호출이 이루어지는 DrawingContext를 통해 발생한다. 예를 들어, 2D에서는 다음이 드로잉 컨텍스트 내에 있을 수 있다.
2D와의 일관성을 위해, 다음과 같은 유사한 모델이 3D에서 제공된다.
이 렌더링 모델은 Retained Mode 3D 비주얼(여기서 "명령들"은 단순히 저장됨) 및 Immediate Mode 3D 비주얼(여기서 렌더링은 직접 발생하며, 카메라는 정면에 설정되어야 한다) 양자에 대해 잘 동작한다. 사실, 유지 모드의 경우, 내부적으로 발생하는 것은 3D 모델링 계층 구조가 구축되고 유지되고 있는 것이다. 대안으로, 즉석 모드의 경우에는, 이러한 일이 발생하지 않으며, 명령들은 직접 발행되고, 컨텍스트 스택(예를 들어 변환을 위한)이 유지되고 있다.
다음은 3D 비주얼 API를 이용한 프로그래밍을 나타내는 예이다. 이 예는 Retained3DVisual을 생성하고, 렌더링할 드로잉 컨텍스트를 취득하고, 원시함수들 및 광들을 그 안에 렌더링하고, 카메라를 설정하고, 비주얼을 제어의 비주얼 자식들에 추가한다.
2D의 3D 안으로의 통합은 중요한 기능이며, 3D 세계에서의 2D UI 상호작용을 3D 표면 상에 맵핑시키는 등의 매우 흥미있는 시나리오를 가능하게 한다. 2D는 개별적인 방법으로 3D 내에 통합된다. 하나의 방법은 3D 원시함수로의 텍스쳐로서 하는 것이다. 임의의 아발론 2D 브러시(더 복잡한 재질 사항은 물론)는 3D를 텍스쳐하는 데 사용될 수 있다. 이것의 특수한 경우는 임의의 비주얼(및 따라서 제어들 또는 전체 애플리케이션 UI들)을 호스트할 수 있는 VisualBrush이다. 히트 테스팅을 분해하고 그렇게 하기를 바라는 애플리케이션들에 대해 그 비주얼 내로 더 히트 테스트하기 위한 메커니즘이 제공되며, 소정의 경우, 히트 테스팅 분해는 그러한 비주얼들이 존재할 수 있도록 행해진다. 비주얼 자체는 비트맵이 아니므로 비주얼 텍스쳐링은 비주얼 내의 2D 형상을 취하고 이것을 3D로 가져와서 2D 비트맵 이 아닌 3D 벡터 그래픽을 텍스쳐로서 사용하는 것과 같은 보다 복잡한 기술을 통해 구현될 수 있다.
2D를 3D로 통합하는 또 하나의 방법은 3D 컨텍스트 상의 렌더링 명령으로서 하는 것이다. 예를 들어 구, 2D 비주얼 및 육면체를 스택하면서 이들 모두가 동일 z-버퍼를 여전히 허용하고, 따라서 예를 들어 구가 2D UI의 일부를 통해 전달되는 것을 허용하기 위해 특정 z 깊이에서 어떠한 시각 효과도 없이 스크린 정렬되고 스케일링되지 않은 2D 비주얼을 단순히 렌더링할 수 있는 것이 또한 바람직하다. 이것은 Drawing3DContext 상의 "DrawVisual" 명령에 의해 노출된다.
전술한 바와 같이, 애니메이션은 직관적으로 동작해야 하며, 2D 애니메이션 기술은 직접 3D로 전송할 수 있다. 예외는 타임라인들을 합리화(rationalize)한다.
위의 설명은 드로잉 명령들이 컨텍스트로 발행되는 불가피한 렌더링 이용 스타일을 나타낸다. 이것은 선언적인 이용(decalarative usage)이 아니며, 따라서 이 불가피한 접근 방법은 선언적 마크업에는 적절하지 않다.
위의 메커니즘에서는 외부적으로 명시적으로 구축되고 있는 3D 모델이 존재하지 않으므로(내부적으로는 존재하더라도), 프로그래머는 3D 모델에 어드레스하거나 그의 콘텐츠를 열거할 수 없다. 결과적으로, 모델을 입력으로서 취하여 새로운 모델을 생성하는 "효과들"을 기록할 장소가 존재하지 않는다.
브러시, 펜, 형상, 경로 등을 갖는 2D에서와 같이 3D "자원들"을 구축하고 이용하는 선언적 방법을 제공하기 위하여, 사용자들로 하여금, 3D 명령 스트림에 들어가는 것을 구축하도록 할 수 있는 다수의 타입이 제공되며, 구축된 객체는 컨텍스트를 사용하는 대신 Retained3DVisual 내에 설정될 수 있다.
예를 들어, 위의 Drawing3DContext 기반 샘플 코드는 다음과 같이 재기록될 수 있다.
여기서, 모델이 구축되고 있으며, 이어서 Retained3DVisual 내로 할당된다. PushTransform/Pop 쌍들은 그 아래의 변환 및 모델들을 자체적으로 갖는 Model3DCollection의 구축에 의해 대체된다. 모델링 접근법 및 불가피한 컨텍스트 기반 접근법 양자의 제공은 요소 레벨 선언적 마크업, 비주얼 목록, 장면 그래프 효과들 및 비주얼 콘텐츠의 수정가능성에 대한 솔루션을 제공하며, 구조적으로 가능한 방식으로 행해진다.
모델링 클래스 트리의 루트는 Retained3DVisual에 첨부될 수 있는 3차원 모델을 나타내는 Model3D이다. 결과적으로, 광, 메쉬(mesh), .X 파일 스트림(따라서 파일, 자원, 메모리 등으로부터 나타날 수 있다), 모델 그룹 및 3D 배치된 2D 비주얼들은 모두 모델이다. 따라서, 다음의 계층 구조가 존재한다.
Model3D 클래스 자체는 3D 경계 박스 취득, Model3D의 Transform의 취득 및 설정, 음영 모드와 같은 다른 노드 레벨 속성들의 취득 및 설정, 및 hitTestObject의 취득 및 설정을 포함하는 다수의 연산을 지원한다. 명시적 3D 개시 히트 테스 팅은 3D 장면 내에 노출되지 않는다는 점에 유의한다. 즉, 무엇이 히트되는지를 알기 위해 임의 방향의 광선을 3D 장면으로 프로젝션하는 API는 존재하지 않는다. 히트 테스팅 기능은 Retained3DVisual에서의 2D 프로젝션에 대해 히트 테스트를 수행함으로써 액세스된다.
3D 통합은 2D 좌표 시스템을 3D 좌표 시스템으로 처리(rationalize)할 때 도전을 받는다. 2D에서, 좌표 시스템은 좌상에 원점을, 우측으로 x+를, 아래로 y+를 갖는다.
3D 좌표 시스템은 오른손잡이 시스템일 수 있는데, 이 시스템에서 +z는 스크린의 밖으로 나오는 것이고, +x는 우측으로(2D와 동일), +y는 위로(2D와 다름) 가는 것이다. 이것은 3D 그래픽 컨텍스트에서의 왼손잡이 좌표 시스템이 많은 수의 불필요한 프로그래밍 에러를 발생시키는 경향이 있기 때문이다. 현대의 하드웨어는 퍼-버텍스 쉐이더(per-vertex shader)를 다운로드하여 원하는 어떠한 좌표 시스템 규정도 사용할 수 있는 능력을 갖고 있다는 점에 유의한다.
좌표 시스템 합리화의 또 하나의 국면은 텍스쳐가 존재하는 u,v 공간이다. u,v 공간에 대해서는 특정 디폴트 규정이 존재하지 않지만, "v+ 하향"인 모델들은 "v+ 상향"인 모델들(이들에 대해 텍스쳐는 거꾸로 보일 수 있다)보다 텍스쳐링을 통해 더 직접적인 2D UI의 맵핑을 허용한다. 텍스쳐되고 있는 모델이 적절히 배향된(oriented) u,v 그리드를 갖지 않는 경우, Material의 Brush들 상의 Transform 속성은 반작용에 사용될 수 있다.
텍스트를 3D에서 매력적으로 보이게 하는 가장 가능성 있는 방법을 찾기 위 해 다수의 경험이 수행되었다(이것은 폭, 높이 및 깊이를 가진 3D 텍스트를 꼭 의미하지는 않는다는 점에 유의한다). 이 때문에, 애플리케이션은 3D에서 사용될 텍스트(및 다른 임의의 2D 요소들)를 유지하는 2D 비주얼들을 구축하고, 이 비주얼이 오버샘플링된 후(예를 들어 4x-8x만큼), 이 비주얼을 평면 또는 임의의 3D 객체 상의 Material로서 사용하는 것을 보장할 수 있다. 결과적인 텍스쳐링이 이방성(anisotropic)인 경우, 결과는 매력적인 텍스트이다.
이 섹션에서 지정되는 선언적 타입들(예를 들어, 벡터, 점, 라이트, 메쉬, 재질, 원시함수, 변환 등)은 모두 표준 XAML CLR 클래스 타입 설명 메커니즘을 이용하는 XAML 기반 마크업을 통해 쉽게 설명될 수 있다는 점에 유의하자. 타입들은 TypeConverter를 가질 수 있지만, 그렇지 않은 경우, 이들은 XAML이 제공하는 표준 단순 및 복합 속성 설명 메커니즘을 통해 마크업에서 지정할 수 있다. TypeConverter 사양들은 이들이 XAML에서 나타날 때 타입들의 순전한 스트링 기반 표현들을 해석하기 위한 것이라는 점에 유의한다. 따라서, 예를 들어, ScaleTransform3D에서 사용되는 Vector3D에 대해, XAML 마크업은 다음과 같을 것이다.
"ScaleTransform3D" 및 "scaleVector"는 범용 XAML 파서에 의해 분석되고 이해되지만, "1,2,8"이 Vector3D의 TypeConverter에 공급되어 Vector3D(이것은 ScaleTransform3D의 "ScaleVector" 속성의 타입이기 때문)를 생성할 것으로 예측된 다는 점에 유의한다. 또한, 각각의 타입에 대해 명시적으로 열거되지 않았지만, 이들 타입은 다음의 메소드를 갖는다는 점에 유의한다(여기서는 Vector3D에 대해 도시되지만, 다른 것들에도 적용 가능하다).
또한, Changeable로부터(직접 또는 간접적으로) 도출되는 임의의 타입은 "공개적인 새로운 MyType Copy()" 메소드를 가질 필요가 있다. 이러한 원시 함수 타입들은 단순히 이 섹션에서 설명되는 나머지 타입들을 지원하기 위해 존재한다. 가능할 때마다, 이들은 2D에서 사용된 원시함수 타입들을 미러링하며, 이 유사성은 이러한 타입에 대한 설계 목표이다.
Point3D 객체는 2D Point 타입 System.Windows.Point에 대한 간단한 유사물(analog)이다.
Vector3D는 2D Vector 타입 System.Windows.Vector의 간단한 유사물이다.
Point4D는 3D 점에 제4의, w 성분을 더하며, 논-어파인 Matrix3D를 통한 변환에 사용된다. 1인 'w' 컴포넌트가 Point3D로 변환되고, 0인 'w' 컴포넌트가 Vector3D로 변환될 때에는 Vector4D는 존재하지 않는다.
4원수(Quaternion)는 3차원에서 회전을 표현하는 별개의 3D 엔티티이다. 이들의 능력은 유연하고 신뢰성 있는 보간을 달성하기 위해 4원수들 사이에 보간(따라서 애니메이트)할 수 있다는 것이다. 이 특정 보간 메커니즘은 구형 선형 보간으로 알려져 있다.
4원수는 이들의 성분들(x,y,z,w)의 직접적인 사양으로부터, 또는 축/각도 표현으로서 구축될 수 있다. 제1 표현은 정규화되지 않은 4원수를 생성할 수 있는데, 이에 대한 소정의 연산은 이해되지 않는다(예를 들어 축 및 각도의 추출).
4원수의 성분들은 4원수가 구축된 경우에는 설정될 수 없는데, 이는 그렇게 하는 데에는 잠재적인 모호성이 존재하기 때문이며, 그 예로 비정규화된 4원수 상에 각도를 설정하는 것은 어떠한 의미도 갖지 않는다.
Matrix3D는 System.Windows.Matrix에 대한 3D 유사물이다. Matrix와 같이, 대부분의 API는 Matrix3D를 취하는 대신, 깊은 방법으로 애니메이션을 지원하는 Transform3D를 취한다. 3D 연산을 위한 행렬들은 4x4 행렬로 표현된다. MIL은 행 벡터 신택스를 사용한다:
행렬이 점과 승산될 때, 행렬은 그 점을 새로운 좌표 시스템에서 이전 좌표 시스템으로 변환한다.
변환은 임의의 레벨로 중첩될 수 있다. 새로운 변환이 적용될 때마다, 이는 이것을 현재의 변환 행렬로 사전 승산하는 것과 동일하다.
Transform3D는 2D Transform과 같이 특정 타입의 3D 변환을 표현하는 구체적 인 서브 클래스들을 갖는 추상 기본 클래스이다. Transform3D의 특정 서브 클래스는 또한 애니메이션이 나타나는 곳이다.
일 실시예에서, Transform3D의 전체 계층 구조는 아래에 설명되어 있다:
루트 Transform3D는 Transform의 특정 클래스들을 구축하기 위한 정적 메소드들을 갖는다(이것은 변환이 더 넓을 수 있기 때문에 Matrix3D 표현을 노출시키지 않는다는 점에 유의한다).
Point3D/Vector3D를 취하는 Transform() 메소드는 변환이 어파인이 아닌 경우 예외를 발생시킨다는 점에 유의한다.
Transform3DCollection은 TransformCollection을 모방하며, Add* 메소드들은 위의 Create* 메소드들이 수정되는 것과 동일한 방식으로 수정된다.
AffineTransform3D는 구체적인 어파인 3D 변환들(이동, 왜곡, 회전, 스케일링)이 도출되는 기본 클래스이며, Matrix3D에 대한 판독 액세스를 노출시킨다:
TranslateTransform3D:
ScaleTransform3D:
RotateTransform3D는 회전축(따라서 4원수의 사용)의 개념의 도입으로 인해 단지 2D 회전으로부터의 단순한 맵핑 이상이다.
4원수 속성만이 애니메이트 가능하다는 점에 유의한다. 일반적으로, 축/각도의 애니메이션은 잘 동작하지 않는 경향이 있다. 4원수를 보다 양호하게 애니메이트하여, 4원수의 기본 값으로부터 축 및 각도를 추출할 수 있다. 고정축에 대해 단순히 각도를 애니메이트하기를 원하는 경우, 이것을 지정하는 쉬운 방법은 이들의 위치를 나타내는 2개의 4원수를 구축하고, 이들 사이에서 애니메이트하는 것이다.
MatrixTransform3D는 Matrix3D로부터 직접 Transform3D를 구축할 수 있다.
Transform3D 타입 속성이 마크업에서 지정될 때, 속성 시스템은 스트링 표현을 적절한 변환 도출 객체로 변환하기 위해 Transform 타입 변환기를 사용한다. 애니메이트된 속성들은 이 신택스를 사용하여 설명되지 않지만, 복합 속성 신택스는 애니메이션 설명을 위해 사용될 수 있다.
신택스는 2D Transform으로부터 모델링되는데, 여기서 "<>"는 선택적인 파라미터를 나타낸다.
다음은 문법의 예이다.
Retained3DVisual은 Visual로부터 도출되며, 그렇게 함으로써 불투명도, 2D Geometric Clip, 2D Blend Mode, Hit Testing API, 2D Bounds 질의 및 비주얼 트리에의 참여를 포함하는 그의 속성들을 취득한다. 불투명도, 클립, 혼합 모드 및 경계들 모두는 3D 장면의 2D 프로젝션에 적용된다.
ViewPort 박스는 카메라/모델 조합에 의해 결정되는 프로젝션이 2D 로컬 좌표 공간에서 어디로 맵핑되는지를 설정한다. Retained3DVisual 상에는 Bounds3D 메소드가 존재하지 않는다는 점에 유의한다. 이것은 Models.Bounds로서 이용가능하다.
Drawing3DContext는 2D DrawingContext과 매우 유사하며, RenderOpen/RenderAppend를 통해 Retained3DVisual의 Model3DCollection으로부터 액세스 가능하다. 이것은 명령을 내부적으로 유지하지만 즉석 모드 렌더링 컨텍스트와 유사하다.
이 Drawing3DContext 연산들의 시맨틱에 대한 특정 상세는 모델링 API를 참조하여 아래에 설명되는데, Drawing3DContext는 이 모델링 API에 대한 이기이다. 예를 들어, DrawImportedPrimitive(ImportedPrimitive3DSource primitiveSource, objectHitTestToken)는 ImportedPrimitive3D를 생성하며, 이를 현재 축적되는 Model3D(이것은 컨텍스트 상의 Push/Pop 메소드에 의해 조작된다)에 추가한다.
DrawModel()은 컨텍스트 세계와 모델링 세계 사이의 또 하나의 교차점이며, Model3D가 컨텍스트 내에 드로잉되는 것을 허용한다. Drawing3DContext로부터의 명시적인 "리드백(read back)"은 없는데, 이는 이것이 이것을 지원하는 Model3DCollection을 가지며, 그 컬렉션이 필요에 따라 열거될 수 있기 때문이다.
모델링 API는 이들 클래스에 대한 공개적인 보호 API이며(상속 멤버들을 보이지 않음), 여기서 Model3D는 모든 것이 구축되는 추상 모델이다.
Model3DCollection은 모델들의 조합이 구축되어 하나의 단위로 취급되는 곳이며, 선택적으로 다른 특성들을 변환하거나 이들에게 적용한다.
Model3DCollection은 또한 Drawing3DContext를 리턴하는 RenderOpen/Append를 갖는다는 점에 유의한다. 이 컨텍스트의 사용은 ModelCollection 자체를 수정한다. RenderOpen()과 RenderAppend() 사이의 차이는 RenderOpen()이 컬렉션을 먼저 소거한다는 것이다. 또한, 이 실시예에서 Model3DCollection 상에서 한번에 하나의 Drawing3DContext만이 열릴 수 있으며, 그것이 열릴 때, 애플리케이션은 그 Model3DCollection의 콘텐츠에 직접 액세스(판독 또는 기록을 위해)할 수 없다는 점에 유의한다.
라이트들은 Model3D의 것이다. 이들은 Ambient, Positional, Directional 및 Spot 라이트를 포함한다. 라이트는 모델링 계층 구조의 일부인 추가 속성을 가지며, 따라서 좌표 공간 변환된다. 라이트 상에는 주변, 확산 및 반사 칼라들이 제공된다. 계층적으로 범위가 지정되거나 특정 볼륨으로 범위가 지정되는 라이트는 존재하지 않는다는 점에도 유의한다. 적당한 라이트의 계층 구조가 아래에 설명된다.
기본 라이트 클래스는 추상 클래스이다.
주변 라이트(ambient light)는 이들의 모양에 관계없이 객체를 불균일하게 조명한다.
방향성 라이트는 공간 내의 위치를 갖지 않으며, 이들의 라이트들은 이것을 정의하는 벡터에 의해 지정되는 특정 방향을 따라 프로젝트한다.
방향은 정규화될 필요는 없지만, 0이 아닌 크기를 가져야 한다.
위치 라이트는 공간 내의 위치를 가지며, 이들의 라이트를 모든 방향으로 프로젝트한다. 라이트의 열화(falloff)는 감쇠(attenuation) 및 범위 속성에 의해 제어된다.
PointLight는 SpotLight가 제3자가 아니라 그로부터 도출될 수 있도록 하기 위해 strongname 상속 요구를 가져야 한다는 점에 유의하자.
SpotLight는 위치, 범위 및 감쇠를 가지므로 PointLight로부터 도출되지만, 또한 라이트의 "콘(cone)"을 제어하기 위한 방향 및 파라미터를 추가한다. 콘을 제어하기 위하여, outerConeAngle(이것을 넘어서는 아무 것도 조명되지 않는다) 및 innerConeAngle(이 안의 모든 것은 완전히 조명된다)이 지정되어야 한다. 내부 콘과 외부 콘의 외측 사이의 조명은 선형으로 저하된다. (내부 콘과 외부 콘의 에지 사이의 각 열화, 및 라이트의 위치에 대한 거리에서의 열화가 존재하며, 감쇠 및 범위에 의해 영향을 받는다는 점에 유의한다.)
MIL API 내의 어디에서나와 같이, 각도는 도로 지정된다는 점에 유의하자.
Primitive3D는 트리 내의 렌더링을 유발하는 리프 노드(leaf note)이다. 구체적인 클래스들은 도입된 원시함수(.x 파일들)는 물론 명시적으로 지정된 메쉬들을 가져온다. 구축자는 내부적(internal)이다(확장성은 MeshPrimitive3D를 통해 이용가능하다).
MeshPrimitive3D는 메쉬 및 재료(material)로의 모델링을 위한 것이다.
MeshPrimitive3D는 리프 형상이며, 메쉬를 포함하지만 그 자체는 아니라는 점에 유의한다. 이것은 메쉬가 메쉬 데이터를 복제하지 않고 상이한 히트 테스팅을 받는 상이한 재질들과 함께 다수의 MeshPrimitive3D 사이에서 공유된다는 것을 의미한다.
ImportedPrimitive3D는 도입되어 적절한 내부 형태로 변환된 외부적으로 취득된 원시함수(잠재적으로 재료(material) 및 애니메이션을 가짐)를 나타낸다. 이는 리지드 모델(rigid model)로서 취급된다. 이에 대한 일반적인 예는 .X 파일이 며, XFiles을 명시적으로 도입하는 ImportedPrimitive3DSource의 서브 클래스가 존재한다.
.x 파일들은 장면들에 공통으로 포함되는 것으로 예측되므로, 이것을 표현하기 위한 간단한 TypeConverter 포맷이 다음과 같이 지원된다.
VisualModel3D는 임의의 비주얼(2D, 정의에 의해)을 취하여, 장면 내에 배치한다. 렌더링시, 이것은 스크린 정렬되며, 그 크기는 영향을 받지 않지만, 카메라로부터 특정 z-평면에 있게 된다. 이 비주얼은 상호작용하도록 유지된다.
VisualModel3D의 렌더링은 먼저 CenterPoint를 세계 좌표로 변환한다. 이어 서, 비주얼을 스크린 정렬 방식으로 픽셀 버퍼 내에 렌더링하는데, 변환된 CenterPoint의 z는 비주얼의 중심이 배치되는 곳이다. 카메라 모션 하에, VisualModel3D는 스크린 부동산의 동일 양을 점유하며, 순방향 대면하고, 라이트에 영향을 받지 않는 등등일 것이다. 장면의 나머지에 대한 비주얼의 카메라 모션 동안의 고정 점은 이 점에 기초하여 변위가 발생하므로 비주얼의 중심일 것이다.
제공되는 비주얼은 완전히 상호작용하며, 결과적으로 그것을 둘러싸는 Retained3DVisual의 자식이 되는데, 이는 비주얼이 단일 부모만을 가질 수 있는 것과 같이 주어진 비주얼이 임의의 VisualModel3D에서 한번만 사용될 수 있다는 것을 의미한다. 이것은 상호작용 비주얼을 3D 내에 삽입하는 2개의 메커니즘 중 하나라는 점에 유의한다. 다른 하나는 VisualMaterial을 사용하고 이것을 원시함수 상에 사용하는 것이다.
DrawMesh 및 DrawVisual 양자는 hitTestToken "객체"를 취한다. 이것은 3D 비주얼이 히트를 취득할 때 IVisual.HitTest()에 의해 리턴된다. 이어서, 이것은 3D에서 히트를 취득한 것을 명확히 하기 위해 사용된다. 여기서, 각각의 DrawMesh는 동일 메쉬를 취득하지만 상이한 hitTestToken을 제공받을 수 있기 때문에 경로 선택(pick paths)이 필요하지 않다는 점에 유의한다.
일 실시예에서, HitTesting은 히트 간격, 히트 점의 u,v 좌표를 제공하고, 최초 히트 객체를 넘어선 히트 테스팅을 허용하는 등등을 행하는 Direct3DRayIntersect 유틸리티를 통해 구현된다. 히트 테스팅 결과는 히트된 원시함수의 u,v 좌표를 제공하기에 충분한 정보를 가져, 어떤 텍스쳐가 그것을 랩핑 하고 있었던지 히트 테스트 질의로의 변환을 허용한다. 또한, VisualMaterial의 사용은 물론 VisualModel3D에 대해, 히트 테스트는 올바른 맵핑 점에서 2D 비주얼로 진행한다. 이것은 히트 테스트 컨텍스트가 외부의 2D 환경으로부터 들어와서 3D 환경을 통해 계속하고 중첩된 2D 환경에서 다시 잠재적으로 영원히 선택하는 것을 허용함으로써 결과된다. 이것의 최종 결과는 이러한 통과가 제공될 때, 라이브, 텍스쳐 맵핑된 아발론 2d 제어로의 사용자 상호작용이 적절히 동작하는 것이다.
본 발명은 외부 소스로부터 3D 원시함수를 도입하는 일반적인 개념을 지원한다. v1에서 이것에 대한 일 실시예는 .x 파일 포맷으로부터 이다.
.X 파일들은 XFile3DSource로서 시스템 내로 들어오며, ImportedPrimitive3D를 구축하는 데 사용된다. 이것은 개별 데이터 타입으로 분리되어, 다수의 ImportedPrimitive3D에서 사용되고 공유될 수 있다. .x 파일에 적절한 변환 및 처리는 이것의 구축시에 발생하거나 연기될 수 있다. .x 파일들은 하나의 단위로서 도입되며, 그의 내측의 어떤 것도 개별적으로 어드레스될 수 없다는 점에 유의한다.
Mesh3D 원시함수는 프로그램으로 구축될 수 있는 간단한 삼각 원시함수이다(인덱싱 및 비인덱싱 사양 모두를 허용). 이것은 원시함수의 가장 일반적인 사용일 것으로 예상되는 것을 지원한다(즉, 위치, 정상, 칼라 및 텍스쳐 정보, 이들 중 마지막 세개는 옵션임). 메쉬는 또한 삼각형, 선 또는 점으로 표시될 것인지에 대한 선택을 허용한다. 이것은 또한 인덱스를 해석하기 위한 3개의 토폴로지, 즉 삼각형 리스트, 삼각형 스트립 및 삼각형 팬을 지원한다.
Mesh3D에 의해 직접 지원되지 않는 버텍스 포맷 및 다른 원시함수 구성에 대해 .x 파일이 구축되고 도입될 수 있다.
MeshPrimitiveType는 다음과 같이 정의된다.
Mesh3D 내의 퍼-버텍스 데이터는 Positions, Normals, Colors 및 TextureCoordinates로 분할된다. 이 중에서, Positions만이 필요하다. 나머지 중 임의의 것이 제공되는 경우, 이들은 Positions 컬렉션과 정확히 동일한 길이를 가져야 하며, 그렇지 않은 경우 예외가 발생한다.
Normals는 제공될 경우 정규화되는 것으로 가정된다. 시스템은 토폴로지/근사에 기초하여 Normals를 계산하려고 시도하지 않으며, 대신 Normals이 필요할 때 이들이 제공되어야 한다.
TriangleIndices 컬렉션은 메쉬를 구성하는 삼각형들에 대한 퍼-버텍스 정보를 결정하기 위하여 버텍스 데이터로 인덱스되는 멤버들을 갖는다. 이 컬렉션은 MeshPrimitiveType의 설정에 기초하여 해석된다. TriangleList에 대해, TriangleIndices 컬렉션 내의 모두 3개의 요소들은 새로운 삼각형을 정의한다. TriangleFan에 대해, 인덱스들 0,1,2는 제1 삼각형을 정의하며, 각각의 후속 인덱스 i는 꼭지점 0,i,i-1에 의해 주어지는 새로운 삼각형을 결정한다. TriangleStrip에 대해, 인덱스 0,1,2는 제1 삼각형을 결정하며, 각각의 후속 인덱스 i는 꼭지점 i-2,i-1,i에 의해 주어지는 새로운 삼각형을 결정한다. LineList, LineStrip 및 PointList는 유사한 해석을 갖지만, 렌더링은 삼각형이 아니라 선 및 점에 의존한다.
TriangleIndices가 공백이면, Mesh는 인덱스되지 않은 원시함수로서 구현되는데, 이는 길이 n의 Positions 컬렉션에 대한 값들 0,1,...,n-2,n-1을 유지하는 TriangleIndices와 동일하다.
Mesh의 구축시, 그 구현은 이 메쉬를 표현하는 최적의 D3D 구조를 생성한다. 이때, 실제 컬렉션 데이터 구조는 데이터의 복제를 방지하기 위해 메쉬 구현에 의해 폐기될 수 있다. 소정의 다른 메커니즘을 통해(예를 들어 Retained3DVisuals 모델 계층 구조를 트래버스하는 메커니즘) 액세스되는 경우 메쉬의 후속 리드백은 오리지날 데이터를 유지하는 것이 아니라 유지되고 있는 D3D 정보로부터 데이터를 재구축할 수 있다.
메쉬는 Changeable로부터 (Animatable을 통해) 도출되며, 따라서 수정될 수 있다. 그 구현은 세트들을 버텍스 및 인덱스 데이터로 트랩하고 이러한 변경을 D3D 데이터 구조로 전파하는 것을 필요로 한다. 메쉬에서 버텍스 또는 인덱스 데 이터의 선언적 애니메이션들에 대한 명시적인 지원은 존재하지 않는다. 즉, 예를 들어 Point3DAnimationCollections는 여기서 보이지 않는다. 이것은 예를 들어 2D 다중선 경로와 일관된다.
다른 타입들과 같이, XAML 복합 속성 신택스는 Mesh3D를 정의하는 컬렉션들을 지정하는 데 사용될 수 있다. 그러나, 이것은 어렵고 장황할 수 있으며, 따라서 사양을 보다 간결하게 만들기 이해 TypeConverters가 제공된다.
메쉬 내에 정의된 각각의 컬렉션은 컬렉션을 생성하기 위해 분석되고 사용될 수들의 단일 스트링을 취할 수 있다. 예를 들어, 위치들 및 칼라만을 가진 인덱스된 삼각 스트립을 나타내는 메쉬가 다음과 같이 지정될 수 있다.
물론, 이들 중 어느 것은 복합 속성 신택스에서 훨씬 더 장황하게 표현될 수 있다.
Primitive3D를 구축하는 메소드들은 이들의 모습을 정의하기 위한 Material를 취한다. Material은 3개의 구체적인 서브 클래스, 즉 BrushMaterial, VisualMaterial 및 AdvancedMaterial을 가진 추상 기본 클래스이다. BrushMeterial 및 VisualMaterial은 BasicMaterial이라고 하는 또 하나의 추상 클래스의 서브 클래스들이다. 따라서:
BrushMaterial 메소드는 단일 브러시를 취하며, 투명성의 달성(픽셀 또는 칼라), 텍스쳐 변환(심지어 애니메이트 변환), 비디오 텍스쳐 사용, 암시적인 자동 생성 비트맵 등을 포함하는 광범위한 효과를 위해 사용될 수 있다. 구체적으로, 솔리드 칼라, 이미지, 그래디언트 또는 심지어 또 하나의 비주얼을 텍스쳐링하기 위해, SolidColorBrush, ImageBrush, GradientBrush 또는 VisualBrush가 BrushMaterial을 생성하는 데 사용될 수 있다.
VisualMaterial 메소드는 비주얼로부터 재질을 구축하도록 설계된다. 이 재질은 입력이 그것이 삽입되는 3D 세계로부터 비주얼로 전달된다는 점에서 상호작용한다. 이것과 VisualBrush를 가진 BrushMaterial 사이의 하나의 차이는 BrushMaterial이 상호작용하지 않는다는 점이다.
AdvancedMaterial 클래스는 BrushMaterial 또는 VisualMaterial을 단순히 사용하는 것보다 훨씬 복잡하지만 추가적인 유연성을 제공한다.
재질들은 브러시에 기초하여 유연성 및 개념의 경제성을 얻는다. 예를 들어, 비디오 텍스쳐, 그래디언트 텍스쳐 등과 같은 것들을 반사하는 개별 텍스쳐 계층구조가 존재할 필요가 없는데, 이는 이들이 모두 브러시로서 지정 가능하기 때문이다. 브러시들은 이미 알파 마스크 및 스칼라 투명도 값을 캡슐화하며, 따라서 이들은 텍스쳐링에 이용 가능하게 된다. 브러시들은 이미 이들과 관련된 2D Transform을 갖는데, 텍스쳐링의 경우, 이것은 메쉬 내의 uv 좌표를 텍스쳐로 맵핑되도록 변환하기 위한 텍스쳐 변환으로서 해석된다. 브러시들은 우드 그레인 쉐이더와 같은 스톡 절차 쉐이더를 매달기 위한 올바른 장소이다. 이것은 2D에서 Fill 또는 펜으로서, 3D에서 텍스쳐로서 사용될 수 있다. 어떠한 특정 API 지원도 절차 쉐이더에 대한 3D 공간에 주어질 필요가 없다.
픽셀 또는 버텍스 쉐이더는 그 대부분이 파라미터화되는 스톡 쉐이더들로서 제공될 수 있다는 점에 유의한다. 이들이 API에서 액세스될 수 있는 방법은 2D 세계에서 이해되는 쉐이더들에 대해 이들이 브러시의 구체적인 서브 클래스들로서 노출되고, 이들의 파라미터화가 클래스 상의 구축자를 통해, 또는 클래스 상의 속성 들로서 표현되는 것이다. 그러면, 이들은 2D 객체들에 적용될 수 있다. 3D에서만 이해되는 쉐이더들은 Material의 구체적인 서브 클래스로서(아마도 BasicMaterial의 서브 클래스로서) 노출되는데, 이들은 또한 이들의 구축자를 통해 파라미터화될 수 있다. 이어서, 이러한 노출은 쉐이더들이 3D(그리고 적절한 경우 2D) 메쉬들에 적용되는 것을 허용한다.
전술한 바와 같이, BrushMaterial은 브러시를 캡슐화한다. Primitive3D에 적용되는 BrushMaterial은 텍스쳐로서 취급된다. 텍스쳐들은 직접 맵핑되는데, 즉 맵핑되고 있는 원시함수 상의 2D u,v 좌표는 텍스쳐 변환에 의해 수정되는, 텍스쳐 상의 대응 x,y 좌표로 직접 인덱스된다. 다른 2D와 같이, 텍스쳐의 좌표 시스템은 좌상에서 (0,0)으로부터 실행되는데, 양의 y는 하향이다.
브러시에 사용되는 VisualBrush는 입력을 허용하지 않지만, 그 위의 임의의 애니메이션에 따라, 또는 그에 대해 발생하는 임의의 구조적 변경에 따라 갱신된다. 비주얼을 Material로 사용하고 입력을 수신하기 위하여, VisualMaterial이 아래와 같이 사용된다.
전술한 바와 같이, VisualMaterial은 상호작용 비주얼을 캡슐화한다. 이것은 비주얼이 그의 텍스쳐 형태로 계속 존재한다는 점에서 비주얼과 함께 사용되는 BrushMaterial과 다르다. 맵핑이 원시함수와 관련된 u,v 그리드에 기초하므로, 사용자 입력이 그의 2D 대응물과 완전한 충실도를 갖지 못하는 상황이 존재한다는 점에 유의한다. 예를 들어, 2D 제어가 마우스를 캡쳐하는 마우스 캡쳐 시나리오를 고려하자(예를 들어 스크롤 바 행동을 구현하기 위해). 이 시나리오에서, 마우스는 스크롤 바로부터 벗어나는 것이 허용되지만, 시스템은 예를 들어 마우스가 스크롤 바에 대해 어떤 y 위치에 있는지를 파악하고 적절히 동작할 수 있다. 제어가 u,v 그리드를 가진 원시함수 상에 텍스쳐링되고, 마우스가 원시함수로부터 벗어나는 상황에서는, 일반적으로 이러한 결정을 만들 방법이 없다. 이것에 대응하도록 작성하면서 행할 수 있는 소정의 것들이 있지만, 일반적으로 이것은 2D 공간으로 맵핑을 제한할 것이다. 비주얼은 결과적으로 소정의 방식으로 루트 Retained3DVisual의 자식이 된다는 점에 유의한다. 일 실시예에서, 프레임워크가 제어들의 단일 부모화에 기초한다는 사실로 인해, 둘 이상의 Material에서 단일 UiElement를 사용하거나, 두 장소 이상에서 VisualMaterial을 사용하는 것은 불법이다.
BrushMaterials/VisualMaterials 및 BumpMaps는 AdvancedMaterials를 정의하는 데 사용된다.
EnvironmentMaps는 정육면체 맵핑을 가능하게 하는 특정 포맷인 것으로 예상되는 텍스쳐들이라는 점에 유의한다. 특히, 정육면체 맵의 여섯 면은 텍스쳐(브러시 상의 3x2 그리드와 같은 어떤 것일 수 있다)와 관련된 브러시의 섹션들에서 표현되어야 한다. Ambient, Diffuse 및 Specular 속성들은 일반적인 Material이 아니라 BasicMaterial을 취하는데, 이는 이들이 AdvancedMaterials 자체로서 지정되는 것이 허용되지 않기 때문이라는 점에 유의한다. 또한, 환경 맵들은 단지 BrushMaterials인데, 이는 VisualMaterial이 제공하는 상호작용성이 환경 맵들에 대해 이해되지 않기 때문이라는 점에 유의한다.
Bump 맵들은 텍스쳐들과 같이 원시함수들 상의 텍스쳐 좌표들을 통해 3D 원시함수들로 맵핑되는 그리드들이다. 그러나, 보간된 데이터는 표면의 Normals에 대한 섭동으로서 해석되며, 원시함수의 불균일한 모습을 유발한다. 이것을 달성하기 위하여, 범프 맵들은 정상 섭동과 같은 정보 및 잠재적으로 다른 정보를 지닌다. 이들은 칼라 또는 투명성 정보를 갖지 않는다. 이 때문에, 브러시를 범프 맵으로 사용하는 것은 부적절하다. 따라서, 새로운 BumpMap 클래스가 특정 픽셀 포 맷의 ImageSource로서 제공될 수 있다.
Material은 브러시의 스트링 사양이 BrushMaterial로 자동 승진하는 것을 허용하는 단순 TypeConverter를 제공한다.
이것은 다음과 같은 사양을 허용한다.
형상 계층 구조 내의 임의의 레벨에 삽입될 수 없는 모델의 주변 파라미터들이 제공될 수 있다. 예를 들어, 포그는 Retained3DVisual 상에 Fog 속성을 설정함으로써 장면에 추가될 수 있는데, 예를 들어 이용 가능한 Fog는 픽셀 포그이다. 포그는 아래 나타난 바와 같이 추상 클래스 및 계층구조로서 표현된다.
fogDensity는 0-1의 범위를 가지며, 포그의 밀도의 정규화된 표현이다. fogStart 및 fogEnd는 장치 공간 [0,1]에 지정된 z 깊이를 포함하며, 포그가 시작되고 끝나는 곳을 나타낸다.
Camera는 3D 모델이 2D 비주얼로 프로젝트되는 메커니즘이다. ProjectionCamera는 Position, LookAtPoint 및 FieldOfView와 같은 잘 이해되는 파라미터들을 취하여 카메라를 구축한다. MatrixCamera는 World-To-Device 변환을 정의하는 데 사용되는 Matrix3D를 취한다.
Retained3DVisual에서, Camera는 Model3D 상에 뷰를 제공하는 데 사용되며, 결과적인 프로젝션은 Retained3DVisual 상에 설정된 2D ViewPort로 맵핑된다. Retained3DVisual의 2D 경계 박스는 단순히 3D 모델의 프로젝트된 3D 경계 박스이며, 그의 볼록하고 축 정렬된 외피로 랩핑되고, 비주얼 상에 설정되는 클립으로 클립된다는 점에 유의한다.
ProjectionCamera는 카메라가 Position, LookAtPoint 및 FieldOfView와 같은 파라미터들로부터 구축되게 하는 수단이다. 이것은 원근 프로젝션 및 정사영 프로 젝션 양자를 캡슐화한다. 도 42는 뷰잉 및 위치를 나타내는 ProjectionCamera의 관련 국면들의 양호한 표시를 제공한다(여기서 FieldOfView는 수평 방향에 있어야 한다).
FieldOfView는 뷰의 수평 필드를 나타내며, 도로 지정된다는 점에 유의한다(다른 MIL 각도와 같음). Near 및 Far PlaneDistances는 LookDirection 벡터를 따른 카메라의 위치로부터의 3D 세계 좌표 거리를 나타낸다. NearPlaneDistance는 0을 디폴토로 하며, FarPlaneDistance는 무한대를 디폴트로 한다.
실제 프로젝션시, NearPlaneDistance 및 FarPlaneDistance가 여전히 각각 0 및 무한대인 경우, 이 모델은 검사되고, 그의 경계 볼륨은 카메라 프로젝션에 따라 프로젝트된다. 이어서, 결과적인 경계 볼륨이 검사되어, 가까운 평면 거리는 카메 라 위치에 가장 가까운 LookDirection에 수직한 경계 볼륨의 평면으로 설정된다. 이것은 본질적으로 가장 먼 평면을 사용하는 것 외에는 먼 평면에 대해 동일하다. 이것은 여전히 전체 모델을 표시하면서 z-버퍼 해상도의 최적 이용을 가능하게 한다. IsOrthographic가 참인 경우, 정사영 프로젝션이 사용되며, FieldOfView는 무시된다.
ProjectionCamera의 파라미터들에 의해 정의되는 프로젝션 평면은 Retained3DVisual 상의 ViewPort 사각형으로 맵핑되며, 이것은 3 공간에서 2 공간으로의 최종 전이를 나타낸다는 점에 유의한다.
Camera의 MatrixCamera 서브 클래스는 Matrix를 프로젝션 변환으로 직접 지정하기 위한 수단을 제공한다. 이것은 자신의 프로젝션 행렬 계산 메커니즘을 가진 애플리케이션들에 유용하다.
MinimumZ 및 MaximumZ 값은 z-버퍼 범위를 직접 제어한다는 점에 유의한다. 이들은 Matrix의 프로젝션 행렬로서의 적용 후에 고려된다.
결과적인 프로젝션은 Retained3DVisual 상의 ViewPort 사각형으로 맵핑되며, 이것은 3 공간에서 2 공간으로의 최종 전이를 나타낸다.
다음은 XAML에서 전체 Model3D 계층 구조의 사양을 나타내는 보다 완전한 마크업들이다. 신택스 중 일부는 변경될 수 있다는 점에 유의한다.
다음의 예는 2개의 도입된 .x 파일들 및 이들 중 하나 상의 회전 변환 및 0,1,0에서 위에 위치하는 단일 백색 점 라이트를 구비한 모델을 간단하게 생성한다.
이 마크업은 파일, 스트림, 자원 또는 임의의 적당한 엔티티에 있을 수 있다. 클라이언트 프로그램은 그 XAML의 로딩을 호출하고, 이것은 또한 필요에 따라 애플리케이션에 의해 사용될 완전한 Model3DCollection을 구축한다.
다음 예는 복합 속성 XAML 신택스의 사용을 통해 명시적으로 선언된 MeshPrimitive3D를 제공한다. 메쉬는 옐로우에서 레드로 LinearGradient에 의해 텍스쳐링된다. 또한, 장면 내에는 라이트가 있다.
이 예는 제1 .x 파일을 취하고, XAML 지정된 애니메이션에 추가한다. 이러한 특정 예는 1x에서 2.5x로 5초 이상 .x 파일을 스케일링하는 균일한 스케일을 추가하고, 반대로 하고, 무한히 반복한다. 이것은 또한 그의 스케일을 슬로우-인/슬로우-아웃하기 위해 가속/감속을 사용한다.
이 예는 .x 파일을 도입하고, 라이브 UI를 그의 재질로서 적용한다.
XAML은 자원들을 참조하기 위한 신택스를 지원한다. 이 컨텍스트 내의 "자원들"은 넓은 의미이며, XAML 파일의 자원 섹션은 물론 관리된 어셈블리의 관리된 자원 "포크(fork)"로부터의 로딩을 포함한다. 양 메커니즘들은 지원되며, 자원들은 이들을 공유하기 위해 여러 장소에서 참조될 수 있다. 현재 네이티브 Win32 자원들을 직접 로딩하기 위한 메커니즘은 없지만, IResourceLoader 인터페이스의 구현이 그것을 허용한다.
이것은 XAML과 직접 관련은 없지만, 메쉬 및 재질와 같은 것들을 공유하는 애플리케이션이 어떻게 구축되는지에 관련된다. 3D 모델링 객체들(Lights, Model3DCollections, MeshPrimitive3D's, Materials, Mesh3D, Brush 등)은 Changeable 타입이다. 전술한 바와 같이, 변경가능 값들은 개념적으로는 깊은 사본을 만들지만 사실은 온 디맨드 얕은 복제를 행하는 Copy() 메소드를 제공한다. 이 Copy() 메소드의 사용은 객체들의 최적의 공유를 유발하며 이들 객체의 서브 파트들이 변경되는 것을 허용한다.
사각형, 다각형, 타원 등과 같은 2차원 모양들은 그 자체는 UiElement인 Shape 클래스를 통해 윈도우 프리젠테이션 프레임워크로 도입된다. 사각형과 같은 모양들은 Canvas 상에 배치될 수 있는데, 캔버스 자체는 모양들의 컨테이너로서 사용되는 UiElement이다. 다음의 일례이다.
이 경우, Canvas는 UiElement이며, 사각형 및 선은 각각의 UiElement이다. 이 경우, 캔버스 내에 포함된 모든 것은 UiElement이다.
그러나, 이 예를 나타낸 바와 같이, 마크업에서 경로들의 조합을 고려하자.
이 경우, CircleGeometry, RectangleGeometry(즉, Path.Data 내부에 있는 것) 자체는 UiElement가 아니지만, Path 컨테이너는 UiElement이다.
요소 레벨 "3D Shape"는 Retained3DVisual의 3D 속성이 비주얼 자체를 넘지 못한다는 점에서 문제를 유발한다. 즉, 2개의 비주얼의 콘텐츠는 z에서 상호 투과하지 못한다(예를 들어, 하나는 애플 비주얼을 꿰뚫는 화살 비주얼을 가질 수 없다). Controls 및 Shapes는 비주얼로부터 도출되므로, 이것은 또한 상호 투과 Controls 및 Shapes를 갖는 것에 대한 지원이 없다는 것을 의미한다. 이들은 항상 이들의 콘텐츠의 2D 프로젝션이다.
3D 객체들이 요소 레벨에서 상호 투과하도록 하기 위하여, 또한 마크업에서 이것을 표현하기 위하여, 필요한 상호 투과성을 가진 복합 3D 모델을 포함할 수 있는 Viewport3D 요소가 제공된다. 그러나, 이것은 z에서 임의의 다른 Viewport3D들과 상호작용하지 않는다(그리고 이것은 3D 공간 내의 2D Viewport이므로 Viewport3D라고 한다).
Viewport3D는 Shape가 도출되는 동일 클래스(FrameworkElement 또는 Control)로부터 도출된다. Viewport3D는 Shape로부터 도출되어서는 안되는데, 이는 Shape가 3D에 대해 이해되지 않는 Fill, Stroke 등의 속성을 갖기 때문이다. 따라서, Viewport3D, Shape 및 Image는 모두 형제들이다. Viewport3D는 Shape 상에 존재하는 속성들의 일부(Top, Left, Width, Height, Transform 및 Clip)를 포함하는 설정 가능한 다수의 속성을 갖는다. 이 속성들은 3D에서 무관하지만, UiElement인 Viewport3D에 해당하는 3D의 2D 프로젝션에 대해 이해된다.
Viewport3D는 또한 그와 관련된 카메라(그리고 적절한 디폴트가 제공된다)는 물론 포그와 같은 3D 장면 광범위(scene-wide) 속성들(즉, Retained3DVisual 상에 도 있는 속성들)을 갖는다. Viewport3D는 모양을 통해 제공될 3D 객체들의 컬렉션을 표현하는 Model3DCollection 값을 갖는 속성(그 자체는 Model3D)을 갖는다. 애플리케이션이 z에서 상호작용하도록 허용하기를 원하는 것이 무엇이든 단일 Viewport3D에 대한 단일 Model3DCollection 내에 배치된다.
카메라가 지정되지 않는 경우, 프로젝션을 제공하는 디폴트 카메라가 사용되어, Top, Left, Width, Height에 의해 결정되는 Viewport3D 경계들이 모델로 채워지고, near/far 클립 평면들이 모델의 바로 앞에 그리고 바로 뒤에 설정되며, 카메라는 z축을 내려보고 y는 상향이다. 라이트들이 지정되지 않는 경우, y축을 하향 지시하는 백색 방향성 라이트가 암시적으로 사용된다.
View3D에 대한 마크업은 위에 도시된 Path에 대한 것과 유사한데, 이는 이것이 non-UiElements가 경로 마크업의 내측에 지정되는 예이기 때문이다. 다음은 View3D 마크업의 일례이다.
<View3D> 태그들 내측에, Model3DCollection 값을 가진 멤버가 개별 마크업 지정된 Model3D들로부터 채워진다. 태그들과 Model3D의 서브 클래스들 사이에는 일대일 맵핑이 존재한다는 점에 유의한다. 또한, 이 예에서 제2 메쉬는 마크업 지정 제어(이 경우 Button)를 포함하는 비주얼 재질을 갖는다는 점에 유의한다. 이 제어는 완전히 상호작용하며, OnClick 등을 지정할 수 있다.
View3D의 직계 자식 노드들은 Model3D들인데, 이는 디폴트 컬렉션이 Models 컬렉션이기 때문이다. 이들의 신택스는 일반적으로 복합 속성 신택스에서의 <Viewport3D.Model>의 사양을 요구하도록 변경될 수 있다. 이 마크업은 규칙적인 2D 마크업이 예를 들어 재질을 정의하고 다수의 장소에서 이것을 사용하기 위해 따르는 자원들에 대한 동일 경로를 따른다. 이 기능은 일반 자원 메커니즘에 의해 제공된다.
일반적으로, 히트 테스팅은 UiElement 또는 Control 레벨에서 발생한다. 그러나, 히트 테스팅은 Viewport3D 전체 상에 제한되거나 그렇지 않은 경우에는 모델들을 다수의 Viewport3D로 분할하는 것을 요구하고 이들 상에서 히트 테스트할 것이다. 그러나, 이들이 다수의 Viewport3D 내에 있자마자, 이들은 더 이상 동일한 3D 환경의 일부가 아니다. 이것은 "id"는 물론, 마크업 또는 코드 내의 Model3D의 개별 멤버들 상에 이벤트 핸들러가 지정되는 것을 허용함으로써 분해된다. 히트 테스팅이 분해될 때, 적절한 메소드가 호출되며(송신자는 여전히 Viewport3D 전체일 것이다), 식별자는 EventArgs의 일부로서 내려오게 된다. 그러면, 애플리케이션들은 상이한 이벤트 핸들러들에서, 또는 "id"의 스위칭 오프에 의해 그들의 로직을 격리시킬 수 있어야 한다.
VisualMaterial의 사용은 히트 테스팅이 그 내장 요소 내로 진행되어야 한다는 시스템에 대한 표시이다. 시스템은 이것이 실제로 발생하는 것을 보장한다. 따라서, 히트 테스트 연산은 2D에서 3D로, 다시 2D로 전이된다. 다음은 Viewport3D에 대한 API 사양이다.
3D에서 투명성을 올바르게 행하기 위해, 원시함수들(및 한계에서 개별 삼각형들)은 백에서 프론트로 렌더링하도록 분류되며, 이에 따라 z-버퍼는 참여하지 않는다. 이것은 올바른 혼합을 보장하기 위해 필요하다.
EmbeddingHostVisual이 또한 제공된다. 이것은 외부자에 의해 구축될 수 없고 내부적으로만 구축될 수 있는 비주얼의 서브 클래스이다. EmbeddingHostVisual은 지정된 비주얼이 부모/자식이 아니라 비주얼 대 비주얼의 관계에 대한 "삽입 호스트"로서 사용되고 있는 것을 나타내는 비주얼을 포함한다. 3D 장면에 삽입된 2D 비주얼들은 이것의 또 하나의 예이다. 효과들은 비주얼들 사이의 부모/자식이 아 닌 관계의 또 하나의 예일 수 있다.
아래에 정의가 설명된다.
EmbeddingHostVisual "부모"에 대한 관계는 일반적인 부모/자식 관계가 아닌 것으로 정의되므로, 이것은 비주얼들 사이의 변환을 추출하는 것과 같은 판독 서비스들이 균일한 맵핑의 부재로 인해 이해되지 못한다는 것을 의미한다. 이러한 연산들은 3D 서브 시스템 자체에서 처리되지만, 그 메커니즘은 Retained3DVisual에 고유하다는 점에 유의한다.
매체
MediaData는 첨부된 부록에서도 설명되는 다음의 객체를 통해 임의의 오디오/비디오 콘텐츠를 재생하는 데 사용될 수 있다:
AudioData 객체는 오디오 데이터에 대해 제공된다.
VideoData 객체는 비디오 데이터에 대해 제공된다.
요소 레벨 Video 객체도 제공된다.
요소 레벨 Audio 객체도 제공된다.
결론
전술한 상세한 설명으로부터 알 수 있듯이, 프로그램 코드에 장면 그래프와 인터페이스하는 능력을 제공하는 인터페이스 및 객체 모델을 포함하는 매체 통합 계층이 제공된다. 시스템, 메소드 및 객체 모델은 사용이 간단하고, 강력하며, 유연하고 확장 가능하다.
본 발명은 다양한 수정 및 대체 구성들이 가능하지만, 소정의 실시예들이 도면에 도시되고, 위에 상세히 설명되었다. 그러나, 본 발명을 개시된 특정 형태로 제한하려는 의도는 없으며, 그와 반대로 본 발명은 본 발명의 사상 및 범위 내에 있는 모든 수정, 대체 구성 및 균등물을 커버하는 것을 의도한다.
Claims (67)
- 출력으로의 처리를 위해 컴퓨터 그래픽 데이터를 배열하는 방법에 있어서,매체 통합 계층(media integration layer)의 인터페이스를 통해, 그래픽 관련 데이터에 대응하는 함수 호출(function call)을 수신하는 단계; 및상기 함수 호출에 기초하여 장면 그래프 데이터 구조(scene graph data structure) 내의 데이터를 수정하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 비주얼 클래스(visual class)의 새로운 인스턴스를 초기화하는 함수를 호출(invoke)하는 단계를 포함하는 방법.
- 제2항에 있어서, 상기 비주얼과 연관된 변환(transform)에 대응하는 인터페이스를 통해 함수 호출을 수신하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 드로잉 비주얼 클래스의 새로운 인스턴스를 초기화하는 함수를 호출하는 단계를 포함하는 방법.
- 제4항에 있어서, 렌더링을 위해 상기 드로잉 비주얼 인스턴스를 개시(open)하는 인터페이스를 통해 함수 호출을 수신하고, 이에 응답하여 상기 드로잉 비주얼로의 렌더링을 위한 메커니즘을 제공하는 드로잉 컨텍스트를 리턴하는 단계를 더 포함하는 방법.
- 제1항에 있어서,상기 함수 호출과 연관된 브러시 데이터(brush data)를 수신하는 단계를 더 포함하고,상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는,상기 장면 그래프로부터 하나의 프레임이 렌더링될 때, 하나의 영역이 상기 브러시 데이터에 대응하는 가시 데이터(visible data)로 채워지도록, 상기 장면 그래프 데이터 구조 내의 데이터 구조를 수정하는 브러시 함수를 호출하는 단계를 포함하는 방법.
- 제6항에 있어서, 상기 브러시 데이터를 수신하는 단계는 솔리드 칼라(solid color)에 대응하는 데이터를 수신하는 단계를 포함하는 방법.
- 제6항에 있어서, 상기 브러시 데이터를 수신하는 단계는 리니어 그래디언트 브러시(linear gradient brush) 및 적어도 하나의 스톱을 포함하는 스톱 컬렉션(stop collection)에 대응하는 데이터를 수신하는 단계를 포함하는 방법.
- 제6항에 있어서, 상기 브러시 데이터를 수신하는 단계는 래디컬 그래디언트 브러시(radial gradient brush)에 대응하는 데이터를 수신하는 단계를 포함하는 방법.
- 제6항에 있어서, 상기 브러시 데이터를 수신하는 단계는 이미지에 대응하는 데이터를 수신하는 단계를 포함하는 방법.
- 제10항에 있어서, 상기 이미지에 적용될 이미지 효과(image effect)에 대응하는 인터페이스를 통해 함수 호출을 수신하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 함수 호출과 연관된 펜 데이터(pen data)를 수신하는 단계를 더 포함하고, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 모양의 윤곽을 정의하는 펜 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 타원(ellipse)을 표현하는 형상 관련 함수(geometry-related function)를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단 계는 상기 장면 그래프 데이터 구조 내의 사각형을 표현하는 형상 관련 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 경로(path)를 표현하는 형상 관련 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 선을 표현하는 형상 관련 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 비주얼의 히트 테스팅(hit-testing)과 관련된 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 비주얼의 좌표 변환과 관련된 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단 계는 상기 장면 그래프 데이터 구조 내의 비주얼의 경계 박스(bounding box) 계산과 관련된 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 비주얼 객체에 대한 공통 인터페이스(common interface)를 통해 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 적어도 하나의 비주얼 객체의 트리를 렌더링 타겟으로 렌더링하는 비주얼 관리자를 호출하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내에 컨테이너 객체를 배치하는 함수를 호출하는 단계를 포함하고, 상기 컨테이너 객체는 적어도 하나의 비주얼 객체를 포함하도록 구성되는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내에 이미지 데이터를 배치하는 함수를 호출하는 단계를 포함하는 방법.
- 제23항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단 계는 상기 이미지 데이터와 연관된 상기 장면 그래프 데이터 구조 내에 이미지 효과 객체를 배치하는 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내에 텍스트에 대응하는 데이터를 배치하는 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 함수 호출에 응답하여 드로잉 컨텍스트를 제공하는 함수를 호출하는 단계를 포함하는 방법.
- 제26항에 있어서, 상기 함수 호출은 유지 비주얼(retained visual)에 대응하고, 상기 유지 비주얼의 상기 드로잉 컨텍스트로 하여금 상기 장면 그래프 데이터 구조로 리턴되도록 콜 백(call back)하는 단계를 더 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내에 3차원 비주얼을 배치하는 함수를 호출하는 단계를 포함하는 방법.
- 제28항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단 계는 상기 3차원 비주얼 상에 2차원 표면을 맵핑(mapping)하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내에 애니메이션 데이터를 배치하는 함수를 호출하는 단계를 포함하는 방법.
- 제30항에 있어서, 상기 애니메이션 데이터에 대응하는 타임라인(timeline) 정보를 상기 매체 통합 계층의 다른 계층에 있는 구성 엔진(composition engine)으로 전송하는 단계를 더 포함하는 방법.
- 제31항에 있어서, 상기 구성 엔진은 상기 타임라인에 기초하여 그래픽 데이터를 보간(interpolate)하여 상기 장면 그래프 데이터 구조 내의 객체에 대응하는 출력을 애니메이션화(animate)하는 방법.
- 제1항에 있어서, 상기 매체 통합 계층의 인터페이스를 통해 함수 호출을 수신하는 단계는 마크업을 수신하는 단계를 포함하고, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 마크업을 객체의 인터페이스에 대한 호출로 분해(parsing)하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내에 오디오 및/또는 비디오 데이터에 대응하는 객체를 배치하는 함수를 호출하는 단계를 포함하는 방법.
- 제1항에 있어서, 상기 장면 그래프 데이터 구조 내의 데이터를 수정하는 단계는 상기 장면 그래프 데이터 구조 내의 객체의 가변 값(mutable value)을 변경하는 단계를 포함하는 방법.
- 컴퓨팅 환경에 있어서,출력으로 렌더링될 수 있는 데이터를 포함하기 위한, 그리고 관측될 수 있는 후속 통합 출력(subsequent integrated output)을 위한 계층화된 시스템(layered system)의 장면 그래프 데이터 구조; 및상기 장면 그래프 데이터 구조 내에 포함될 수 있는 객체들 및 다른 데이터를 포함하는 객체 모델 - 상기 객체 모델의 객체들 중 적어도 일부는 상기 장면 그래프 데이터 구조의 콘텐츠를 수정하는 함수들을 호출하기 위한 인터페이스들을 가짐 -을 포함하는 시스템.
- 제36항에 있어서, 상기 장면 그래프 데이터 구조 내에 비주얼 객체들의 트리를 배치하도록 적어도 하나의 함수가 호출되는 시스템.
- 제37항에 있어서, 호출될 때 상기 비주얼 객체들의 트리를 렌더링 타겟으로 렌더링하는 비주얼 관리자를 더 포함하는 시스템.
- 제37항에 있어서, 상기 비주얼 객체들의 트리는 비주얼 컬렉션 객체에 포함되는 시스템.
- 제36항에 있어서, 상기 장면 그래프 데이터 구조 내에 비주얼 객체를 배치하도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 브러시를 상기 비주얼 객체와 연관시키기 위하여 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 형상(geometry)을 상기 비주얼 객체와 연관시키기 위하여 적어도 하나의 함수가 호출되는 시스템.
- 제42항에 있어서, 상기 형상은 타원 형상, 사각 형상, 선 형상 및 경로 형상을 포함하는 세트 중 적어도 하나를 포함하는 시스템.
- 제40항에 있어서, 변환을 상기 비주얼 객체와 연관시키기 위하여 적어도 하 나의 함수가 호출되는 시스템.
- 제44항에 있어서, 상기 변환은 상기 비주얼 객체의 인식 각도(perceived angle)를 변경하기 위한 회전 변환을 포함하는 시스템.
- 제44항에 있어서, 상기 변환은 상기 비주얼 객체의 인식 크기를 변경하기 위한 스케일 변환을 포함하는 시스템.
- 제44항에 있어서, 상기 변환은 상기 비주얼 객체의 인식 위치를 변경하기 위한 이동 변환(translate transform)을 포함하는 시스템.
- 제44항에 있어서, 상기 변환은 상기 비주얼 객체의 인식 왜곡(skew)를 변경하기 위한 왜곡 변환을 포함하는 시스템.
- 제44항에 있어서, 상기 변환과 연관된 애니메이션 정보를 더 포함하고, 상기 애니메이션 정보는 상기 변환과 연관된 변환 데이터가 시간에 따라 변경되도록 하여 상기 비주얼 객체의 변환을 시간에 따라 애니메이션화하는 시스템.
- 제40항에 있어서, 칼라를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 그래디언트 데이터를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 타일 브러시를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 이미지를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 3차원 데이터를 상기 비주얼 데이터와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 드로잉 원시 함수(drawing primitives)를 포함하는 드로잉을 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 오디오 및/또는 비디오 매체를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 이미지 효과를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 모양(shape)의 윤곽이 어떻게 잡히는지를 설명하도록, 펜을 상기 비주얼 객체와 연관시키기 위해 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 상기 비주얼 객체와 연관된 드로잉 컨텍스트를 얻도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 히트 테스팅 데이터를 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제40항에 있어서, 사각형을 상기 비주얼 객체와 연관시키도록 적어도 하나의 함수가 호출되는 시스템.
- 제61항에 있어서, 소스 사각형(source rectangle)이 상기 비주얼 객체에 대응하는 목적 사각형(destination rectangle)에 맞도록 어떻게 스트레칭되어야 하는지를 설명하기 위해 적어도 하나의 함수가 호출되는 시스템.
- 제61항에 있어서, 콘텐츠가 상기 비주얼 객체에 대응하는 컨테이너 내에 어떻게 수직으로 위치되는지를 설명하도록 적어도 하나의 함수가 호출되는 시스템.
- 제61항에 있어서, 콘텐츠가 상기 비주얼 객체에 대응하는 컨테이너 내에 어떻게 수평으로 위치되는지를 설명하도록 적어도 하나의 함수가 호출되는 시스템.
- 컴퓨팅 환경에서,함수 호출을 수신하기 위한 인터페이스 수단;상기 인터페이스 수단을 통해 수신되는 그래픽 관련 데이터 및/또는 매체 관련 데이터를 장면 그래프로 통합하기 위한 하이 레벨 구성 수단(high-level composition means); 및전송 또는 표시될 수 있는 출력으로 상기 장면 그래프를 변환하는 렌더링 수단을 포함하는 시스템.
- 제65항에 있어서, 상기 렌더링 수단은 하이 레벨 구성 엔진으로부터 수신되는 데이터에 기초하여 관측을 위한 프레임을 구성하는 로우 레벨 구성 수단을 포함하는 시스템.
- 제65항에 있어서, 애니메이션 수단을 더 포함하고, 상기 하이 레벨 구성 엔진은, 가시 데이터의 외관(appearance)을 적어도 2개의 프레임에 걸쳐 보간하여 시간에 따라 상기 가시 데이터를 애니메이션화하기 위해, 상기 로우 레벨 구성 수단 에 타임라인 데이터를 제공하는 시스템.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/693,630 US7511718B2 (en) | 2003-10-23 | 2003-10-23 | Media integration layer |
| US10/693,630 | 2003-10-23 |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| KR20070028202A true KR20070028202A (ko) | 2007-03-12 |
Family
ID=34573199
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| KR1020057009678A KR20070028202A (ko) | 2003-10-23 | 2004-07-28 | 매체 통합 계층 |
Country Status (14)
| Country | Link |
|---|---|
| US (1) | US7511718B2 (ko) |
| EP (1) | EP1623406A4 (ko) |
| JP (1) | JP2007509426A (ko) |
| KR (1) | KR20070028202A (ko) |
| CN (1) | CN1989543A (ko) |
| AU (1) | AU2004279199A1 (ko) |
| BR (1) | BRPI0406378A (ko) |
| CA (1) | CA2501452A1 (ko) |
| NO (1) | NO20052269L (ko) |
| NZ (1) | NZ540116A (ko) |
| RU (1) | RU2360275C2 (ko) |
| TW (1) | TW200515304A (ko) |
| WO (1) | WO2005045584A2 (ko) |
| ZA (1) | ZA200503159B (ko) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20130128566A (ko) * | 2012-05-17 | 2013-11-27 | 엘지전자 주식회사 | 사이니지 콘텐츠 생성 방법 |
| KR20170107160A (ko) * | 2016-03-15 | 2017-09-25 | (주)넥셀 | 그래픽 처리 방법 및 장치 |
Families Citing this family (179)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7330186B2 (en) * | 1999-08-03 | 2008-02-12 | Sony Corporation | Methods and systems for scoring multiple time-based assets and events |
| US6954214B2 (en) * | 2000-10-30 | 2005-10-11 | Microsoft Corporation | Efficient perceptual/physical color space conversion |
| US7456845B2 (en) * | 2000-10-30 | 2008-11-25 | Microsoft Corporation | Efficient perceptual/physical color space conversion |
| US20030128214A1 (en) * | 2001-09-14 | 2003-07-10 | Honeywell International Inc. | Framework for domain-independent archetype modeling |
| US7619633B2 (en) | 2002-06-27 | 2009-11-17 | Microsoft Corporation | Intelligent caching data structure for immediate mode graphics |
| US7161599B2 (en) * | 2001-10-18 | 2007-01-09 | Microsoft Corporation | Multiple-level graphics processing system and method |
| US7612776B2 (en) * | 2002-09-14 | 2009-11-03 | Microsoft Corporation | Functions acting on arbitrary geometric paths |
| US20080195925A1 (en) * | 2003-06-26 | 2008-08-14 | Donna Marie Auguste | Compressed Media Files with Intrinsic Supplementary Content |
| US7219340B2 (en) * | 2003-10-23 | 2007-05-15 | Microsoft Corporation | Changeable class and pattern to provide selective mutability in computer programming environments |
| US7068284B2 (en) * | 2003-11-10 | 2006-06-27 | Microsoft Corporation | Color management system that supports legacy and advanced color management applications |
| US7454696B2 (en) * | 2004-04-09 | 2008-11-18 | International Business Machines Corporation | Method and apparatus for stream based markup language post-processing |
| KR100601952B1 (ko) * | 2004-04-20 | 2006-07-14 | 삼성전자주식회사 | 3차원 그래픽 데이터의 재구성장치 및 방법 |
| US20050243085A1 (en) * | 2004-05-03 | 2005-11-03 | Microsoft Corporation | Model 3D construction application program interface |
| US7145562B2 (en) * | 2004-05-03 | 2006-12-05 | Microsoft Corporation | Integration of three dimensional scene hierarchy into two dimensional compositing system |
| US8031190B2 (en) * | 2004-05-03 | 2011-10-04 | Microsoft Corporation | Translating two-dimensional user input on three-dimensional scene |
| US8068103B2 (en) | 2004-06-24 | 2011-11-29 | Apple Inc. | User-interface design |
| US8130237B2 (en) * | 2004-06-24 | 2012-03-06 | Apple Inc. | Resolution independent user interface design |
| US7719523B2 (en) | 2004-08-06 | 2010-05-18 | Touchtable, Inc. | Bounding box gesture recognition on a touch detecting interactive display |
| US20090019084A1 (en) * | 2004-10-04 | 2009-01-15 | T. Rad Co., Ltd. | Method and system for preloading |
| US7603624B2 (en) * | 2004-10-21 | 2009-10-13 | Microsoft Corporation | System and method for styling content in a graphical user interface control |
| US7551182B2 (en) * | 2005-01-18 | 2009-06-23 | Oculus Info Inc. | System and method for processing map data |
| US7154503B2 (en) * | 2005-03-31 | 2006-12-26 | Microsoft Corporation | Methods and systems for brush composition |
| US7561159B2 (en) * | 2005-05-31 | 2009-07-14 | Magnifi Group Inc. | Control of animation timeline |
| US8799757B2 (en) * | 2005-07-01 | 2014-08-05 | Microsoft Corporation | Synchronization aspects of interactive multimedia presentation management |
| US20070006078A1 (en) * | 2005-07-01 | 2007-01-04 | Microsoft Corporation | Declaratively responding to state changes in an interactive multimedia environment |
| US8020084B2 (en) * | 2005-07-01 | 2011-09-13 | Microsoft Corporation | Synchronization aspects of interactive multimedia presentation management |
| US8108787B2 (en) * | 2005-07-01 | 2012-01-31 | Microsoft Corporation | Distributing input events to multiple applications in an interactive media environment |
| US20070006079A1 (en) * | 2005-07-01 | 2007-01-04 | Microsoft Corporation | State-based timing for interactive multimedia presentations |
| US8656268B2 (en) * | 2005-07-01 | 2014-02-18 | Microsoft Corporation | Queueing events in an interactive media environment |
| US20070006238A1 (en) * | 2005-07-01 | 2007-01-04 | Microsoft Corporation | Managing application states in an interactive media environment |
| US7941522B2 (en) * | 2005-07-01 | 2011-05-10 | Microsoft Corporation | Application security in an interactive media environment |
| US8305398B2 (en) * | 2005-07-01 | 2012-11-06 | Microsoft Corporation | Rendering and compositing multiple applications in an interactive media environment |
| US20070006062A1 (en) * | 2005-07-01 | 2007-01-04 | Microsoft Corporation | Synchronization aspects of interactive multimedia presentation management |
| JP4864432B2 (ja) * | 2005-11-29 | 2012-02-01 | 京セラ株式会社 | イベント駆動型アプリケーションにおけるイベント配送方法 |
| US7737996B2 (en) * | 2005-12-01 | 2010-06-15 | Microsoft Corporation | Techniques for automated animation |
| US8077174B2 (en) * | 2005-12-16 | 2011-12-13 | Nvidia Corporation | Hierarchical processor array |
| US7898542B1 (en) * | 2006-03-01 | 2011-03-01 | Adobe Systems Incorporated | Creating animation effects |
| JP4881048B2 (ja) * | 2006-04-03 | 2012-02-22 | キヤノン株式会社 | 情報処理装置および情報処理方法および情報処理プログラム |
| KR100783679B1 (ko) * | 2006-05-11 | 2007-12-07 | 한국과학기술원 | 데이터 스트림에 기반하는 서비스의 개발, 배치, 제공을용이하게 하는 미들웨어 시스템 |
| US7868879B2 (en) * | 2006-05-12 | 2011-01-11 | Doremi Labs, Inc. | Method and apparatus for serving audiovisual content |
| US7890533B2 (en) * | 2006-05-17 | 2011-02-15 | Noblis, Inc. | Method and system for information extraction and modeling |
| US20070268304A1 (en) * | 2006-05-22 | 2007-11-22 | Microsoft Corporation | Gradient Brush and Stroke |
| US7825937B1 (en) * | 2006-06-16 | 2010-11-02 | Nvidia Corporation | Multi-pass cylindrical cube map blur |
| US8860752B2 (en) * | 2006-07-13 | 2014-10-14 | Apple Inc. | Multimedia scripting |
| US8130226B2 (en) * | 2006-08-04 | 2012-03-06 | Apple Inc. | Framework for graphics animation and compositing operations |
| US9019300B2 (en) * | 2006-08-04 | 2015-04-28 | Apple Inc. | Framework for graphics animation and compositing operations |
| US20080055315A1 (en) * | 2006-09-05 | 2008-03-06 | Dale Ducharme | Method and System to Establish and Animate a Coordinate System for Content on a Display |
| US20080084416A1 (en) * | 2006-10-06 | 2008-04-10 | Microsoft Corporation | User-pluggable rendering engine |
| US8782277B2 (en) * | 2006-10-12 | 2014-07-15 | Siemens Product Lifecycle Management Software Inc. | System and method for time-sensitive URI mapping |
| WO2008055034A2 (en) * | 2006-10-30 | 2008-05-08 | Noblis, Inc. | Method and system for personal information extraction and modeling with fully generalized extraction contexts |
| US8234392B2 (en) * | 2006-11-17 | 2012-07-31 | Apple Inc. | Methods and apparatuses for providing a hardware accelerated web engine |
| US20080130987A1 (en) * | 2006-11-30 | 2008-06-05 | Microsoft Corporation | Color Management of RAW Content from Digital Capture Devices |
| US20080158254A1 (en) * | 2006-12-29 | 2008-07-03 | Hong Jiang | Using supplementary information of bounding boxes in multi-layer video composition |
| JP4981820B2 (ja) * | 2007-01-15 | 2012-07-25 | パナソニック株式会社 | 表示処理装置 |
| US8074227B2 (en) * | 2007-02-08 | 2011-12-06 | Microsoft Corporation | Utilizing a first managed process to host at least a second managed process |
| US9519997B1 (en) * | 2007-03-09 | 2016-12-13 | Pixar | Perfect bounding for optimized evaluation of procedurally-generated scene data |
| US20080244511A1 (en) * | 2007-03-30 | 2008-10-02 | Microsoft Corporation | Developing a writing system analyzer using syntax-directed translation |
| US8108799B2 (en) * | 2007-03-30 | 2012-01-31 | Microsoft Corporation | Remoting of windows presentation framework based applications in a non-composed desktop |
| US20080250424A1 (en) * | 2007-04-04 | 2008-10-09 | Ms1 - Microsoft Corporation | Seamless Window Implementation for Windows Presentation Foundation based Applications |
| US20130342433A9 (en) * | 2007-04-14 | 2013-12-26 | Ananth Sankar | Dynamic backlight control for video displays |
| US8134556B2 (en) * | 2007-05-30 | 2012-03-13 | Elsberg Nathan | Method and apparatus for real-time 3D viewer with ray trace on demand |
| US20090021513A1 (en) * | 2007-07-18 | 2009-01-22 | Pixblitz Studios Inc. | Method of Customizing 3D Computer-Generated Scenes |
| US8884981B2 (en) * | 2007-09-04 | 2014-11-11 | Apple Inc. | Dynamically reconfigurable graphics layer system and method |
| US7941758B2 (en) * | 2007-09-04 | 2011-05-10 | Apple Inc. | Animation of graphical objects |
| JP5424546B2 (ja) * | 2007-09-13 | 2014-02-26 | 京セラドキュメントソリューションズ株式会社 | 画像処理装置及び画像形成システム |
| WO2009038788A1 (en) | 2007-09-21 | 2009-03-26 | Noblis, Inc. | Method and system for active learning screening process with dynamic information modeling |
| US8661096B2 (en) * | 2007-11-05 | 2014-02-25 | Cyberlink Corp. | Collaborative editing in a video editing system |
| JP2009129127A (ja) * | 2007-11-22 | 2009-06-11 | Fujitsu Ltd | プログラムの不変物抽出処理プログラム，処理装置，および処理方法，ならびに該プログラムを記憶する記憶媒体 |
| US8397207B2 (en) * | 2007-11-26 | 2013-03-12 | Microsoft Corporation | Logical structure design surface |
| US8009921B2 (en) * | 2008-02-19 | 2011-08-30 | Xerox Corporation | Context dependent intelligent thumbnail images |
| US8482568B2 (en) * | 2008-03-03 | 2013-07-09 | Pixar | Systems and methods for specifying arbitrary animation controls for model objects |
| US8300060B1 (en) * | 2008-03-31 | 2012-10-30 | The Mathworks, Inc. | Object transformation for object trees utilized with multiprocessor systems |
| US9251548B1 (en) | 2008-03-31 | 2016-02-02 | The Mathworks, Inc. | Object transformation for object trees utilized with multiprocessor systems |
| US8760472B2 (en) * | 2008-04-01 | 2014-06-24 | Apple Inc. | Pixel transforms |
| EP2109304A1 (en) * | 2008-04-07 | 2009-10-14 | Océ-Technologies B.V. | Color management method, module, and program product, and printer ussing said method |
| US9052924B2 (en) * | 2008-04-15 | 2015-06-09 | Microsoft Technology Licensing, Llc | Light-weight managed composite control hosting |
| US9589381B2 (en) | 2008-06-12 | 2017-03-07 | Microsoft Technology Licensing, Llc | Copying of animation effects from a source object to at least one target object |
| US8290971B2 (en) | 2008-09-09 | 2012-10-16 | Applied Systems, Inc. | Method and apparatus for remotely displaying a list by determining a quantity of data to send based on the list size and the display control size |
| US8645822B2 (en) * | 2008-09-25 | 2014-02-04 | Microsoft Corporation | Multi-platform presentation system |
| US20100079474A1 (en) * | 2008-09-30 | 2010-04-01 | Microsoft Corporation | Methods for rendering source content of a file for display on a destination figure |
| US8508537B2 (en) * | 2008-11-17 | 2013-08-13 | Disney Enterprises, Inc. | System and method for dependency graph evaluation for animation |
| US8587610B2 (en) * | 2008-12-12 | 2013-11-19 | Microsoft Corporation | Rendering source content for display |
| KR101194605B1 (ko) * | 2008-12-22 | 2012-10-25 | 한국전자통신연구원 | 시간 연속적 텍스쳐 합성 장치 및 방법 |
| US8174541B2 (en) * | 2009-01-19 | 2012-05-08 | International Business Machines Corporation | Dividing three-dimensional space into location based virtual packets |
| US8477136B2 (en) * | 2009-02-13 | 2013-07-02 | Mobitv, Inc. | Functional presentation layer in a lightweight client architecture |
| US8819570B2 (en) * | 2009-03-27 | 2014-08-26 | Zumobi, Inc | Systems, methods, and computer program products displaying interactive elements on a canvas |
| US9142044B2 (en) * | 2009-05-26 | 2015-09-22 | Oracle International Corporation | Apparatus, systems and methods for layout of scene graphs using node bounding areas |
| US8471858B2 (en) * | 2009-06-02 | 2013-06-25 | Qualcomm Incorporated | Displaying a visual representation of performance metrics for rendered graphics elements |
| US20100312813A1 (en) * | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| US8286084B2 (en) * | 2009-06-08 | 2012-10-09 | Swakker Llc | Methods and apparatus for remote interaction using a partitioned display |
| US20100313244A1 (en) * | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| US20100309196A1 (en) * | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for processing related images of an object based on directives |
| US20100313249A1 (en) * | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| US20100311393A1 (en) * | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for distributing, storing, and replaying directives within a network |
| WO2010144429A1 (en) * | 2009-06-08 | 2010-12-16 | Swakker Llc | Methods and apparatus for processing related images of an object based on directives |
| US20100310193A1 (en) * | 2009-06-08 | 2010-12-09 | Castleman Mark | Methods and apparatus for selecting and/or displaying images of perspective views of an object at a communication device |
| JP5371596B2 (ja) * | 2009-07-13 | 2013-12-18 | キヤノン株式会社 | 情報処理装置、情報処理方法及びプログラム |
| US20110022978A1 (en) * | 2009-07-23 | 2011-01-27 | Rockwell Automation Technologies, Inc. | Intelligent device framework |
| KR101277274B1 (ko) * | 2009-11-27 | 2013-06-20 | 한국전자통신연구원 | 자원 간의 물리적/논리적 관계를 맵핑하는 방법 및 장치 |
| US9021390B1 (en) * | 2010-05-05 | 2015-04-28 | Zynga Inc. | Methods and apparatus for optimized pausing of an embedded application to render pop-up window |
| US8726228B2 (en) * | 2010-07-30 | 2014-05-13 | National Instruments Corporation | Developing programs in a graphical specification and constraint language |
| JP2012060280A (ja) * | 2010-09-07 | 2012-03-22 | Sony Corp | 情報処理装置、情報処理方法、およびプログラム |
| US9396001B2 (en) | 2010-11-08 | 2016-07-19 | Sony Corporation | Window management for an embedded system |
| CN101986307B (zh) * | 2010-11-11 | 2013-08-14 | 东莞宇龙通信科技有限公司 | 一种mime类型插件的生成方法、系统及浏览器 |
| US8689123B2 (en) | 2010-12-23 | 2014-04-01 | Microsoft Corporation | Application reporting in an application-selectable user interface |
| US9176742B2 (en) * | 2010-12-27 | 2015-11-03 | Microsoft Technology Licensing, Llc | Converting desktop applications to web applications |
| US8836699B2 (en) * | 2011-02-04 | 2014-09-16 | Chiung Yu Chen | Generation of landmark architecture and sculpture based on chinese characters |
| US8982132B2 (en) * | 2011-02-28 | 2015-03-17 | Adobe Systems Incorporated | Value templates in animation timelines |
| US20130127849A1 (en) * | 2011-05-26 | 2013-05-23 | Sebastian Marketsmueller | Common Rendering Framework and Common Event Model for Video, 2D, and 3D Content |
| EP2549389A1 (en) * | 2011-07-20 | 2013-01-23 | Axel Springer Digital TV Guide GmbH | Easy 2D navigation in a video database |
| US9563971B2 (en) | 2011-09-09 | 2017-02-07 | Microsoft Technology Licensing, Llc | Composition system thread |
| US8687018B1 (en) | 2011-09-23 | 2014-04-01 | Google Inc. | Collection and confirmation of place metadata and graphic representations of fixed objects displayed in a mapping system |
| US8954475B2 (en) | 2011-11-10 | 2015-02-10 | Microsoft Technology Licensing, Llc | Deep cloning of objects using binary format |
| US9384711B2 (en) | 2012-02-15 | 2016-07-05 | Microsoft Technology Licensing, Llc | Speculative render ahead and caching in multiple passes |
| US9373049B1 (en) * | 2012-04-05 | 2016-06-21 | Amazon Technologies, Inc. | Straight line gesture recognition and rendering |
| US9098186B1 (en) | 2012-04-05 | 2015-08-04 | Amazon Technologies, Inc. | Straight line gesture recognition and rendering |
| US20130278607A1 (en) * | 2012-04-20 | 2013-10-24 | A Thinking Ape Technologies | Systems and Methods for Displaying Animations on a Mobile Device |
| RU2485593C1 (ru) * | 2012-05-10 | 2013-06-20 | Федеральное государственное бюджетное образовательное учреждение высшего профессионального образования "Сибирская государственная геодезическая академия" (ФГБОУ ВПО "СГГА") | Способ построения перспективных карт местности (варианты) |
| US9177533B2 (en) | 2012-05-31 | 2015-11-03 | Microsoft Technology Licensing, Llc | Virtual surface compaction |
| US9286122B2 (en) | 2012-05-31 | 2016-03-15 | Microsoft Technology Licensing, Llc | Display techniques using virtual surface allocation |
| US9230517B2 (en) | 2012-05-31 | 2016-01-05 | Microsoft Technology Licensing, Llc | Virtual surface gutters |
| US9235925B2 (en) * | 2012-05-31 | 2016-01-12 | Microsoft Technology Licensing, Llc | Virtual surface rendering |
| US9021437B2 (en) * | 2012-07-13 | 2015-04-28 | Microsoft Technology Licensing, Llc | Declarative style rules for default touch behaviors |
| US10824680B2 (en) | 2012-10-02 | 2020-11-03 | The Boeing Company | Panoptic visualization document access control |
| US9659237B2 (en) * | 2012-10-05 | 2017-05-23 | Micro Usa, Inc. | Imaging through aerosol obscurants |
| US9075618B2 (en) * | 2012-11-02 | 2015-07-07 | Microsoft Technology Licensing, Llc | Cross-platform data visualizations using common descriptions |
| US10025840B2 (en) * | 2012-12-10 | 2018-07-17 | Koninklijke Philips N.V. | Method and system for making multisite performance measure anonymous and for controlling actions and re-identification of anonymous data |
| US20150379906A1 (en) * | 2012-12-21 | 2015-12-31 | 3M Innovative Properties Company | Systems and methods for rule-based animated content optimization |
| US9098269B2 (en) * | 2013-01-04 | 2015-08-04 | Microsoft Technology Licensing, Llc | System and method to ensure resource access safety with immutable object types |
| CN103198471B (zh) * | 2013-02-28 | 2016-06-08 | 天脉聚源(北京)传媒科技有限公司 | 一种视频的裁切方法及装置 |
| GB201304321D0 (en) | 2013-03-11 | 2013-04-24 | Creative Edge Software Llc | Apparatus and method for applying a two-dimensional image on a three-dimensional model |
| US9171401B2 (en) | 2013-03-14 | 2015-10-27 | Dreamworks Animation Llc | Conservative partitioning for rendering a computer-generated animation |
| US9224239B2 (en) | 2013-03-14 | 2015-12-29 | Dreamworks Animation Llc | Look-based selection for rendering a computer-generated animation |
| US9589382B2 (en) * | 2013-03-15 | 2017-03-07 | Dreamworks Animation Llc | Render setup graph |
| US9230294B2 (en) | 2013-03-15 | 2016-01-05 | Dreamworks Animation Llc | Preserving and reusing intermediate data |
| US9514562B2 (en) | 2013-03-15 | 2016-12-06 | Dreamworks Animation Llc | Procedural partitioning of a scene |
| US9218785B2 (en) | 2013-03-15 | 2015-12-22 | Dreamworks Animation Llc | Lighting correction filters |
| US9626787B2 (en) | 2013-03-15 | 2017-04-18 | Dreamworks Animation Llc | For node in render setup graph |
| US9811936B2 (en) | 2013-03-15 | 2017-11-07 | Dreamworks Animation L.L.C. | Level-based data sharing for digital content production |
| US9659398B2 (en) | 2013-03-15 | 2017-05-23 | Dreamworks Animation Llc | Multiple visual representations of lighting effects in a computer animation scene |
| US9208597B2 (en) | 2013-03-15 | 2015-12-08 | Dreamworks Animation Llc | Generalized instancing for three-dimensional scene data |
| US9307007B2 (en) | 2013-06-14 | 2016-04-05 | Microsoft Technology Licensing, Llc | Content pre-render and pre-fetch techniques |
| US9177413B2 (en) * | 2013-06-26 | 2015-11-03 | Nvidia Corporation | Unique primitive identifier generation |
| US9942622B2 (en) * | 2014-01-24 | 2018-04-10 | Hiperwall, Inc. | Methods and systems for synchronizing media stream presentations |
| US9477998B2 (en) * | 2014-06-01 | 2016-10-25 | Apple Inc. | Performance control for concurrent animations |
| KR20160030701A (ko) * | 2014-09-11 | 2016-03-21 | 삼성전자주식회사 | 인쇄 데이터를 프린터로 전송하는 호스트 디바이스 및 호스트 디바이스가 인쇄 데이터를 렌더링하는 방법 |
| EP3205107A2 (en) | 2014-10-06 | 2017-08-16 | VID SCALE, Inc. | Improved palette coding for screen content coding |
| US10810159B2 (en) * | 2014-10-14 | 2020-10-20 | Microsoft Technology Licensing, Llc. | Modular updating of visualizations |
| US10102664B1 (en) * | 2014-12-03 | 2018-10-16 | Charles Schwab & Co., Inc. | System and method for causing graphical information to be rendered |
| US9836874B2 (en) * | 2015-01-27 | 2017-12-05 | Splunk Inc. | Efficient polygon-clipping technique to reduce data transfer requirements for a viewport |
| US9767122B2 (en) | 2015-01-27 | 2017-09-19 | Splunk Inc. | Efficient point-in-polygon indexing technique to facilitate displaying geographic data |
| US10026204B2 (en) | 2015-01-27 | 2018-07-17 | Splunk Inc. | Efficient point-in-polygon indexing technique for processing queries over geographic data sets |
| US9916326B2 (en) | 2015-01-27 | 2018-03-13 | Splunk, Inc. | Efficient point-in-polygon indexing technique for facilitating geofencing operations |
| US9607414B2 (en) | 2015-01-27 | 2017-03-28 | Splunk Inc. | Three-dimensional point-in-polygon operation to facilitate displaying three-dimensional structures |
| US9733823B2 (en) | 2015-04-01 | 2017-08-15 | Microsoft Technology Licensing, Llc | View activation via hit testing in an asynchronous windowing system |
| US9786081B1 (en) * | 2015-05-14 | 2017-10-10 | Domo, Inc. | Transitioning between visual representations |
| US11373272B2 (en) | 2015-06-05 | 2022-06-28 | MindAptiv, LLC | Digital gradient signal processing system and method for signals comprising at least three dimensions |
| US10037592B2 (en) | 2015-06-05 | 2018-07-31 | Mindaptiv LLC | Digital quaternion logarithm signal processing system and method for images and other data types |
| US10672417B2 (en) * | 2015-10-29 | 2020-06-02 | True Image Interactive, Inc. | Systems and methods for machine-generated avatars |
| US9733999B1 (en) | 2016-03-24 | 2017-08-15 | Wells Fargo Bank, N.A. | Dynamic optimization of application workflows |
| WO2017213234A1 (en) * | 2016-06-10 | 2017-12-14 | Sharp Kabushiki Kaisha | Systems and methods for signaling of information associated with a visual language presentation |
| CN106658145B (zh) * | 2016-12-27 | 2020-07-03 | 北京奇虎科技有限公司 | 一种直播数据处理方法和装置 |
| WO2019037558A1 (zh) | 2017-08-22 | 2019-02-28 | 优酷网络技术（北京）有限公司 | 图像处理方法和装置 |
| WO2019046323A1 (en) | 2017-08-28 | 2019-03-07 | Oxide Interactive, LLC | LAMINATE, SPACE, PROGRAMMABLE AND ASYNCHRONOUS SURFACE GENERATION SYSTEM |
| EP4002282B1 (en) | 2017-10-13 | 2023-04-19 | Dassault Systèmes | Method for creating an animation summarizing a design process of a three-dimensional object |
| US11417044B2 (en) * | 2018-05-20 | 2022-08-16 | Thomas Charley Long | Advanced delay analysis mechanism |
| US10558824B1 (en) | 2019-02-04 | 2020-02-11 | S2 Systems Corporation | Application remoting using network vector rendering |
| US11880422B2 (en) | 2019-02-04 | 2024-01-23 | Cloudflare, Inc. | Theft prevention for sensitive information |
| US10452868B1 (en) * | 2019-02-04 | 2019-10-22 | S2 Systems Corporation | Web browser remoting using network vector rendering |
| US10552639B1 (en) | 2019-02-04 | 2020-02-04 | S2 Systems Corporation | Local isolator application with cohesive application-isolation interface |
| CN110297657B (zh) * | 2019-06-11 | 2023-07-21 | 东南大学 | 一种基于层次上下文的api推荐方法 |
| CN112348748A (zh) * | 2019-08-09 | 2021-02-09 | 北京字节跳动网络技术有限公司 | 图像特效处理方法、装置、电子设备和计算机可读存储介质 |
| CN110764757B (zh) * | 2019-10-22 | 2023-06-09 | 成都九洲电子信息系统股份有限公司 | 一种基于html5的交互式图形绘制引擎 |
| US11488338B2 (en) * | 2020-04-17 | 2022-11-01 | Raytheon Company | Efficient three-dimensional, interactive image rendering |
| CN112001985A (zh) * | 2020-06-30 | 2020-11-27 | 深圳点猫科技有限公司 | 一种基于web浏览器的矢量图形创作平台及创作方法 |
| US20220134222A1 (en) * | 2020-11-03 | 2022-05-05 | Nvidia Corporation | Delta propagation in cloud-centric platforms for collaboration and connectivity |
| CN112597266A (zh) * | 2020-12-16 | 2021-04-02 | 深圳中清龙图网络技术有限公司 | 用于处理游戏模板数据的编辑器生成方法和处理方法 |
| CN113192211B (zh) * | 2021-03-23 | 2023-04-07 | 北京师范大学 | 一种基于3d模型的唐三彩虚拟上色系统及方法 |
| CN113326031B (zh) * | 2021-05-28 | 2023-08-22 | 网易（杭州）网络有限公司 | 属性获取方法和装置 |
Family Cites Families (86)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4209852A (en) * | 1974-11-11 | 1980-06-24 | Hyatt Gilbert P | Signal processing and memory arrangement |
| JP2810231B2 (ja) | 1990-01-30 | 1998-10-15 | ジヨンソン・サービス・カンパニー | ノードを有する分散形ネットワークシステム中のデータの位置付け方法 |
| US5509115A (en) | 1990-08-08 | 1996-04-16 | Peerless Systems Corporation | Method and apparatus for displaying a page with graphics information on a continuous synchronous raster output device |
| US5261041A (en) * | 1990-12-28 | 1993-11-09 | Apple Computer, Inc. | Computer controlled animation system based on definitional animated objects and methods of manipulating same |
| US5852449A (en) * | 1992-01-27 | 1998-12-22 | Scientific And Engineering Software | Apparatus for and method of displaying running of modeled system designs |
| WO1993021636A1 (en) | 1992-04-10 | 1993-10-28 | Avid Technology, Inc. | A method and apparatus for representing and editing multimedia compositions |
| US5987627A (en) | 1992-05-13 | 1999-11-16 | Rawlings, Iii; Joseph H. | Methods and apparatus for high-speed mass storage access in a computer system |
| US5500933A (en) * | 1993-04-28 | 1996-03-19 | Canon Information Systems, Inc. | Display system which displays motion video objects combined with other visual objects |
| WO1994027234A1 (en) * | 1993-05-10 | 1994-11-24 | Taligent, Inc. | Multimedia synchronization system |
| US5555368A (en) * | 1993-12-30 | 1996-09-10 | Taligent | Object-oriented multi-tasking view framework |
| US5912666A (en) * | 1994-08-23 | 1999-06-15 | Object Technology Licensing Corp. | Object-oriented global cursor tool |
| US5745761A (en) | 1994-12-15 | 1998-04-28 | International Business Machines Corporation | Advanced graphics driver architecture with extension capability |
| US5986667A (en) * | 1994-12-22 | 1999-11-16 | Apple Computer, Inc. | Mechanism for rendering scenes using an object drawing subsystem |
| US5732198A (en) | 1995-02-09 | 1998-03-24 | Oki America, Inc. | Host based printing system for printing a document having at least one page |
| US5727141A (en) | 1995-05-05 | 1998-03-10 | Apple Computer, Inc. | Method and apparatus for identifying user-selectable regions within multiple display frames |
| US5790130A (en) | 1995-06-08 | 1998-08-04 | Hewlett-Packard Company | Texel cache interrupt daemon for virtual memory management of texture maps |
| US5930810A (en) * | 1995-08-09 | 1999-07-27 | Taylor Corporation | Printing system with pre-defined user modifiable forms and local and remote printing |
| US5986675A (en) * | 1996-05-24 | 1999-11-16 | Microsoft Corporation | System and method for animating an object in three-dimensional space using a two-dimensional input device |
| US5936632A (en) | 1996-07-26 | 1999-08-10 | Hewlett-Packard Co. | Method for fast downloading of textures to accelerated graphics hardware and the elimination of extra software copies of texels |
| US6275857B1 (en) * | 1996-10-30 | 2001-08-14 | Microsoft Corporation | System and method for freeing shared resources in a computer system |
| US5920325A (en) * | 1996-11-20 | 1999-07-06 | International Business Machines Corporation | Prioritization of background display during animation |
| US6137499A (en) * | 1997-03-07 | 2000-10-24 | Silicon Graphics, Inc. | Method, system, and computer program product for visualizing data using partial hierarchies |
| US6195694B1 (en) * | 1997-03-13 | 2001-02-27 | International Business Machines Corporation | Server for reconfiguring control of a subset of devices on one or more kiosks |
| US6160907A (en) | 1997-04-07 | 2000-12-12 | Synapix, Inc. | Iterative three-dimensional process for creating finished media content |
| CA2257577C (en) * | 1997-04-07 | 2002-03-19 | At&T Corp. | System and method for interfacing mpeg-coded audiovisual objects permitting adaptive control |
| US6215495B1 (en) * | 1997-05-30 | 2001-04-10 | Silicon Graphics, Inc. | Platform independent application program interface for interactive 3D scene management |
| US5924098A (en) | 1997-06-30 | 1999-07-13 | Sun Microsystems, Inc. | Method and apparatus for managing a linked-list data structure |
| US6377263B1 (en) * | 1997-07-07 | 2002-04-23 | Aesthetic Solutions | Intelligent software components for virtual worlds |
| US6314470B1 (en) * | 1997-07-25 | 2001-11-06 | Hewlett Packard Company | System and method for asynchronously accessing a graphics system for graphics application evaluation and control |
| US6154215A (en) * | 1997-08-01 | 2000-11-28 | Silicon Graphics, Inc. | Method and apparatus for maintaining multiple representations of a same scene in computer generated graphics |
| US6654931B1 (en) | 1998-01-27 | 2003-11-25 | At&T Corp. | Systems and methods for playing, browsing and interacting with MPEG-4 coded audio-visual objects |
| US6272650B1 (en) * | 1998-02-03 | 2001-08-07 | Amazing Media, Inc. | System and method for disambiguating scene graph loads |
| US6243856B1 (en) * | 1998-02-03 | 2001-06-05 | Amazing Media, Inc. | System and method for encoding a scene graph |
| US6075532A (en) * | 1998-03-23 | 2000-06-13 | Microsoft Corporation | Efficient redrawing of animated windows |
| US6570578B1 (en) | 1998-04-03 | 2003-05-27 | Avid Technology, Inc. | System for automatic generation of selective partial renderings of complex scenes |
| US6266053B1 (en) * | 1998-04-03 | 2001-07-24 | Synapix, Inc. | Time inheritance scene graph for representation of media content |
| US6237092B1 (en) * | 1998-05-05 | 2001-05-22 | International Business Machines Corp. | Client-server system with central application management allowing an administrator to configure user and group contexts during application configuration without relaunching the application |
| US6631403B1 (en) | 1998-05-11 | 2003-10-07 | At&T Corp. | Architecture and application programming interfaces for Java-enabled MPEG-4 (MPEG-J) systems |
| EP1090505A1 (en) * | 1998-06-26 | 2001-04-11 | General Instrument Corporation | Terminal for composing and presenting mpeg-4 video programs |
| US6731314B1 (en) * | 1998-08-17 | 2004-05-04 | Muse Corporation | Network-based three-dimensional multiple-user shared environment apparatus and method |
| US6487565B1 (en) * | 1998-12-29 | 2002-11-26 | Microsoft Corporation | Updating animated images represented by scene graphs |
| US6411297B1 (en) * | 1999-03-03 | 2002-06-25 | Discreet Logic Inc. | Generating image data |
| US6714201B1 (en) * | 1999-04-14 | 2004-03-30 | 3D Open Motion, Llc | Apparatuses, methods, computer programming, and propagated signals for modeling motion in computer applications |
| US6986101B2 (en) * | 1999-05-06 | 2006-01-10 | International Business Machines Corporation | Method and apparatus for converting programs and source code files written in a programming language to equivalent markup language files |
| US6707456B1 (en) * | 1999-08-03 | 2004-03-16 | Sony Corporation | Declarative markup for scoring multiple time-based assets and events within a scene composition system |
| US7184038B2 (en) * | 1999-09-24 | 2007-02-27 | Sun Microsystems, Inc. | Using render bin parallelism for rendering scene graph based graphics data |
| US6765571B2 (en) * | 1999-09-24 | 2004-07-20 | Sun Microsystems, Inc. | Using a master controller to manage threads and resources for scene-based rendering |
| US6538656B1 (en) * | 1999-11-09 | 2003-03-25 | Broadcom Corporation | Video and graphics system with a data transport processor |
| WO2001040933A2 (en) * | 1999-12-06 | 2001-06-07 | Axiomatic Design Software, Inc. | Method and apparatus for producing software using axiomatic design |
| US7102651B1 (en) * | 1999-12-22 | 2006-09-05 | Adobe Systems Incorporated | Hierarchical 2-D color compositing with blending mode and opacity controls at all levels |
| US7103581B1 (en) | 2000-01-13 | 2006-09-05 | Hewlett-Packard Development Company, L.P. | System and method for pricing print jobs |
| US6833840B2 (en) | 2000-02-14 | 2004-12-21 | Optibase Ltd | PROTO implementation in MPEG-4 |
| JP2001273520A (ja) * | 2000-03-23 | 2001-10-05 | Famotik Ltd | マルチメディアドキュメント統合表示システム |
| US6751655B1 (en) * | 2000-04-18 | 2004-06-15 | Sun Microsystems, Inc. | Method and apparatus for transport of scenegraph information across a network |
| US6717599B1 (en) * | 2000-06-29 | 2004-04-06 | Microsoft Corporation | Method, system, and computer program product for implementing derivative operators with graphics hardware |
| US20020019844A1 (en) | 2000-07-06 | 2002-02-14 | Kurowski Scott J. | Method and system for network-distributed computing |
| WO2002013002A2 (en) * | 2000-08-04 | 2002-02-14 | Intrinsic Graphics, Inc. | Development of graphics hardware and software |
| US6675230B1 (en) * | 2000-08-22 | 2004-01-06 | International Business Machines Corporation | Method, system, and program for embedding a user interface object in another user interface object |
| US7143339B2 (en) * | 2000-09-20 | 2006-11-28 | Sap Aktiengesellschaft | Method and apparatus for dynamically formatting and displaying tabular data in real time |
| US6732109B2 (en) * | 2001-01-31 | 2004-05-04 | The Eon Company | Method and system for transferring information between a user interface and a database over a global information network |
| FR2823942A1 (fr) * | 2001-04-24 | 2002-10-25 | Koninkl Philips Electronics Nv | Dispositif pour une conversion d'un format bifs textuel vers un format bifs binaire |
| US7069503B2 (en) * | 2001-06-04 | 2006-06-27 | Murata Kikai Kabushiki Kaisha | Device and program for structured document generation data structure of structural document |
| US7305011B2 (en) * | 2001-06-14 | 2007-12-04 | International Business Machines Corporation | Periodic broadcast and location of evolving media content with application to seminar and stroke media |
| US7064766B2 (en) * | 2001-10-18 | 2006-06-20 | Microsoft Corporation | Intelligent caching data structure for immediate mode graphics |
| US6919891B2 (en) * | 2001-10-18 | 2005-07-19 | Microsoft Corporation | Generic parameterization for a scene graph |
| US7161599B2 (en) * | 2001-10-18 | 2007-01-09 | Microsoft Corporation | Multiple-level graphics processing system and method |
| JP4297784B2 (ja) | 2001-10-23 | 2009-07-15 | サムスン エレクトロニクス カンパニー リミテッド | マークアップ文書とａｖデータとが記録された情報保存媒体、その記録方法、再生方法及び再生装置 |
| US6626211B2 (en) | 2001-11-27 | 2003-09-30 | Toyoda Gosei Co., Ltd. | Brake hose |
| US7055092B2 (en) * | 2001-12-05 | 2006-05-30 | Canon Kabushiki Kaisha | Directory for multi-page SVG document |
| US20030110297A1 (en) * | 2001-12-12 | 2003-06-12 | Tabatabai Ali J. | Transforming multimedia data for delivery to multiple heterogeneous devices |
| US20040110490A1 (en) * | 2001-12-20 | 2004-06-10 | Steele Jay D. | Method and apparatus for providing content to media devices |
| KR100453225B1 (ko) * | 2001-12-26 | 2004-10-15 | 한국전자통신연구원 | 3차원 가상 현실 구현을 위한 클라이언트 시스템과 이를이용한 가상 현실 구현 방법 |
| US7076332B2 (en) * | 2002-01-18 | 2006-07-11 | National Instruments Corporation | System and method for invoking execution of a sequence of operations that includes motion control, machine vision, and data acquisition (DAQ) functionality |
| WO2003067469A2 (en) * | 2002-02-04 | 2003-08-14 | Mobileaware Technologies Limited | Document transformation |
| US20030210267A1 (en) | 2002-05-13 | 2003-11-13 | Kylberg Robert Lee | Systems and methods for providing asynchronous client rendering in a graphical user interface (GUI) environment |
| WO2004008316A2 (en) * | 2002-07-11 | 2004-01-22 | Raytheon Company | System and method for asynchronous storage and playback of a system state |
| US7436406B2 (en) * | 2002-07-12 | 2008-10-14 | Raytheon Company | Scene graph based display for desktop applications |
| US20040216139A1 (en) * | 2002-08-21 | 2004-10-28 | Rhoda Merlin A. | System controlling test/measurement devices on a network using markup language documents and methods thereof |
| US7240346B2 (en) * | 2002-11-13 | 2007-07-03 | Microsoft Corporation | Method and system for accessing drawing resources |
| US7126606B2 (en) * | 2003-03-27 | 2006-10-24 | Microsoft Corporation | Visual and scene graph interfaces |
| US7486294B2 (en) * | 2003-03-27 | 2009-02-03 | Microsoft Corporation | Vector graphics element-based model, application programming interface, and markup language |
| US7088374B2 (en) * | 2003-03-27 | 2006-08-08 | Microsoft Corporation | System and method for managing visual structure, timing, and animation in a graphics processing system |
| US7466315B2 (en) * | 2003-03-27 | 2008-12-16 | Microsoft Corporation | Visual and scene graph interfaces |
| US7412455B2 (en) * | 2003-04-30 | 2008-08-12 | Dillon David M | Software framework that facilitates design and implementation of database applications |
| US8051389B2 (en) * | 2003-08-26 | 2011-11-01 | Hewlett-Packard Development Company, L.P. | Methods of displaying resources of overlapping but separate hierarchies |
| US7012606B2 (en) * | 2003-10-23 | 2006-03-14 | Microsoft Corporation | System and method for a unified composition engine in a graphics processing system |
-
2003
- 2003-10-23 US US10/693,630 patent/US7511718B2/en not_active Expired - Fee Related
-
2004
- 2004-07-28 KR KR1020057009678A patent/KR20070028202A/ko not_active Application Discontinuation
- 2004-07-28 AU AU2004279199A patent/AU2004279199A1/en not_active Abandoned
- 2004-07-28 NZ NZ540116A patent/NZ540116A/en not_active IP Right Cessation
- 2004-07-28 WO PCT/US2004/024570 patent/WO2005045584A2/en active Application Filing
- 2004-07-28 ZA ZA200503159A patent/ZA200503159B/en unknown
- 2004-07-28 RU RU2005120391/09A patent/RU2360275C2/ru not_active IP Right Cessation
- 2004-07-28 EP EP04779584A patent/EP1623406A4/en not_active Withdrawn
- 2004-07-28 BR BR0406378-3A patent/BRPI0406378A/pt not_active IP Right Cessation
- 2004-07-28 CN CNA2004800014899A patent/CN1989543A/zh active Pending
- 2004-07-28 JP JP2006536594A patent/JP2007509426A/ja active Pending
- 2004-07-28 CA CA002501452A patent/CA2501452A1/en not_active Abandoned
- 2004-07-29 TW TW093122772A patent/TW200515304A/zh unknown
-
2005
- 2005-05-10 NO NO20052269A patent/NO20052269L/no not_active Application Discontinuation
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| KR20130128566A (ko) * | 2012-05-17 | 2013-11-27 | 엘지전자 주식회사 | 사이니지 콘텐츠 생성 방법 |
| KR20170107160A (ko) * | 2016-03-15 | 2017-09-25 | (주)넥셀 | 그래픽 처리 방법 및 장치 |
Also Published As
| Publication number | Publication date |
|---|---|
| ZA200503159B (en) | 2006-10-25 |
| RU2005120391A (ru) | 2006-01-20 |
| EP1623406A2 (en) | 2006-02-08 |
| WO2005045584A3 (en) | 2005-12-15 |
| US20050140694A1 (en) | 2005-06-30 |
| EP1623406A4 (en) | 2009-11-11 |
| AU2004279199A1 (en) | 2005-06-23 |
| TW200515304A (en) | 2005-05-01 |
| NO20052269L (no) | 2005-11-24 |
| AU2004279199A8 (en) | 2008-10-02 |
| NO20052269D0 (no) | 2005-05-10 |
| RU2360275C2 (ru) | 2009-06-27 |
| US7511718B2 (en) | 2009-03-31 |
| BRPI0406378A (pt) | 2005-08-09 |
| JP2007509426A (ja) | 2007-04-12 |
| WO2005045584A2 (en) | 2005-05-19 |
| CN1989543A (zh) | 2007-06-27 |
| CA2501452A1 (en) | 2005-04-23 |
| NZ540116A (en) | 2007-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR20070028202A (ko) | 매체 통합 계층 | |
| RU2324229C2 (ru) | Визуальный и пространственный графические интерфейсы | |
| US7486294B2 (en) | Vector graphics element-based model, application programming interface, and markup language | |
| JP4796500B2 (ja) | ベクトルグラフィックスのためのマークアップ言語およびオブジェクトモデル | |
| JP4796499B2 (ja) | 映像およびシーングラフインターフェイス | |
| Yang | Implementation of 3D graphic editor |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| WITN | Application deemed withdrawn, e.g. because no request for examination was filed or no examination fee was paid |