주요 데이터 구조, 즉 ML 모델의 입력과 출력에 렌더링 파이프라인에서 시작됩니다.
이러한 데이터 구조는 다음과 같습니다.
- 프레임 트리는 어떤 웹을 나타내는, 로컬 노드와 원격 노드로 구성됩니다. Blink 렌더기에 있는 문서만 표시됩니다.
- 변경 불가능한 프래그먼트 트리는 대상의 출력 (및 입력)을 나타냅니다. 레이아웃 제약 조건 알고리즘.
- 속성 트리는 변환, 클립, 효과, 스크롤 계층 구조를 나타냅니다. 문서일 수 있습니다 파이프라인 전체에서 사용됩니다.
- 목록 표시 및 페인트 청크는 래스터 및 레이어화 알고리즘에 대한 입력입니다.
- 컴포지터 프레임은 표면, 렌더링 표면, GPU 텍스처를 캡슐화합니다. GPU를 사용하여 그리는 데 사용되는 타일입니다.
다음 예는 이러한 데이터 구조를 살펴보기 전에 아키텍처 검토에서 가져옴 이 예시가 이 문서 전체에서 사용되어 데이터가 어떻게 적용됩니다.
<!-- Example code -->
<html>
<div style="overflow: hidden; width: 100px; height: 100px;">
<iframe style="filter: blur(3px);
transform: rotateZ(1deg);
width: 100px; height: 300px"
id="one" src="foo.com/etc"></iframe>
</div>
<iframe style="top:200px;
transform: scale(1.1) translateX(200px)"
id="two" src="bar.com"></iframe>
</html>
프레임 트리
Chrome에서 때때로 교차 출처 프레임을 렌더링하도록 선택할 수 있음 렌더링해야 합니다.
예시 코드에는 총 3개의 프레임이 있습니다.
사이트 격리를 사용하면 Chromium은 두 가지 렌더링 프로세스를 사용하여 이 웹페이지를 렌더링합니다. 각 렌더링 프로세스에는 해당 웹페이지의 프레임 트리에 대한 자체 표현이 있습니다.
다른 프로세스에서 렌더링된 프레임은 원격 프레임으로 표현됩니다. 원격 프레임에는 렌더링 시 자리표시자 역할을 하는 데 필요한 최소 정보가 포함됩니다. 예를 들어 크기를 예로 들 수 있습니다. 그렇지 않으면 원격 프레임에는 실제 콘텐츠를 렌더링하는 데 필요한 정보가 포함되지 않습니다.
반면에 로컬 프레임은 표준 살펴보겠습니다 로컬 프레임에는 프레임의 방향을 돌리는 데 필요한 해당 프레임에 대한 데이터 (예: DOM 트리 및 스타일 데이터)를 어떤 것으로 렌더링 및 표시할 수 있습니다.
렌더링 파이프라인은
로컬 프레임 트리 프래그먼트를 참조하세요.
foo.com
를 메인 프레임으로 사용하는 좀 더 복잡한 예를 살펴보겠습니다.
<iframe src="bar.com"></iframe>
다음 bar.com
서브프레임:
<iframe src="foo.com/etc"></iframe>
아직 렌더러가 두 개뿐이지만 현재 세 개의 로컬 프레임이 있습니다.
트리 프래그먼트. foo.com
의 렌더링 프로세스에 두 개,
bar.com
의 렌더링 프로세스:
웹페이지에 대한 하나의 컴포지터 프레임을 생성하려면 Viz는 동시에 각 인스턴스의 루트 프레임에서 컴포지터 프레임을 세 개의 로컬 프레임 트리를 집계합니다. 컴포지터 프레임 섹션도 참고하세요.
foo.com
메인 프레임 및 foo.com/other-page
서브프레임
같은 프레임 트리의 일부이고 같은 프로세스에서 렌더링됩니다.
그러나 두 프레임은 여전히
문서 수명 주기
다른 로컬 프레임 트리 프래그먼트의 일부이기 때문입니다.
이러한 이유로 한 번의 업데이트에서 둘 다에 대해 하나의 컴포지터 프레임을 생성하는 것은 불가능합니다.
렌더링 프로세스에 충분한 정보가 없음
foo.com/other-page
용으로 생성된 컴포지터 프레임을 합성합니다.
foo.com
메인 프레임의 컴포지터 프레임에 직접 전달됩니다.
예를 들어 프로세스 외부 bar.com
상위 프레임은 foo.com/other-url
iframe의 표시에 영향을 미칠 수 있습니다.
iframe을 CSS로 변환하거나 DOM의 다른 요소로 iframe의 일부를 가려서는 안 됩니다.
시각적 속성 업데이트 폭포
기기 배율 및 표시 영역 크기와 같은 시각적 속성은 렌더링된 출력에 영향을 미칩니다. 로컬 프레임 트리 프래그먼트 간에 동기화되어야 합니다. 각 로컬 프레임 트리 프래그먼트의 루트에는 연결된 위젯 객체가 있습니다. 시각적 속성 업데이트는 전파 전에 기본 프레임의 위젯으로 이동합니다. 나머지 위젯으로 확대합니다.
표시 영역 크기가 변경되는 경우를 예로 들 수 있습니다.
이 프로세스는 즉시 이루어지지 않으며 복제된 시각적 속성에도 동기화 토큰이 포함됩니다. Viz 컴포지터는 이 동기화 토큰을 사용하여 모든 로컬 프레임 트리 프래그먼트를 기다립니다. 현재 동기화 토큰으로 컴포지터 프레임을 제출합니다. 이 프로세스를 통해 컴포지터 프레임이 서로 다른 시각적 속성과 혼합되지 않습니다.
변경할 수 없는 프래그먼트 트리
변경할 수 없는 프래그먼트 트리는 렌더링의 레이아웃 단계의 출력입니다. 살펴봤습니다 페이지에 있는 모든 요소의 위치와 크기를 나타냅니다. (변환을 적용하지 않음)
각 프래그먼트는 DOM 요소의 일부를 나타냅니다. 일반적으로 요소당 프래그먼트가 하나만 있으므로 인쇄할 때 여러 페이지로 나뉘면 더 많을 수 있습니다. 또는 열을 사용할 수 있습니다.
레이아웃 후에는 각 프래그먼트를 변경할 수 없게 되며 다시 변경되지 않습니다. 몇 가지 추가적인 제한사항이 추가로 적용됩니다. Google에서 하지 않는 일:
- 아무 '위로' 허용 쉽게 확인할 수 있습니다. 하위 요소는 상위 요소에 대한 포인터를 가질 수 없습니다.
- '풍선' 데이터 분석 하위 요소는 상위 요소가 아닌 하위 요소에서만 정보를 읽습니다.
이러한 제한을 통해 후속 레이아웃에 프래그먼트를 재사용할 수 있습니다. 이러한 제한이 없으면 전체 트리를 재생성해야 하는 경우가 많아 비용이 많이 듭니다.
대부분의 레이아웃은 일반적으로 증분 업데이트입니다. 예를 들어 사용자가 요소를 클릭하면 응답하여 UI의 일부를 업데이트하는 웹 앱 화면에서 실제로 변경된 사항에 비례하여 레이아웃이 작동하는 것이 이상적입니다. 이전 트리를 가능한 한 많이 재사용하여 이를 달성할 수 있습니다. 즉, 일반적으로는 나무의 척추만 다시 빌드하면 됩니다.
미래에는 이 불변의 설계를 통해 흥미로운 일들을 할 수 있을 것입니다. 예를 들어 필요한 경우 스레드 경계를 넘어 변경할 수 없는 프래그먼트 트리를 전달합니다. 다른 스레드에서 후속 단계를 수행하기 위해 매끄러운 레이아웃 애니메이션을 위해 여러 개의 트리를 생성할 수 있습니다. 병렬 예측 레이아웃을 수행할 수 있습니다 또한 멀티스레딩 레이아웃 자체의 잠재력을 제공합니다.
인라인 프래그먼트 항목
인라인 콘텐츠 (일반적으로 스타일이 지정된 텍스트)는 약간 다른 표현을 사용합니다. 상자와 포인터가 있는 트리 구조보다는 트리를 나타내는 플랫 목록에 인라인 콘텐츠를 나타냅니다. 주요 이점은 인라인의 플랫 목록 표현이 빠르고 인라인 데이터 구조를 검사하거나 쿼리하는 데 유용하며 효율적으로 사용할 수 있습니다 이는 웹 렌더링 성능에 매우 중요하므로 텍스트 렌더링이 매우 복잡하기 때문입니다. 고도로 최적화하지 않으면 파이프라인에서 가장 느린 부분이 될 수 있습니다.
플랫 목록은 인라인 서식 컨텍스트 인라인 레이아웃 하위 트리의 깊이 우선 검색 순으로 나열됩니다. 목록의 각 항목은 (객체, 하위 요소 수)의 튜플입니다. 다음 DOM을 예로 들어 보겠습니다.
<div style="width: 0;">
<span style="color: blue; position: relative;">Hi</span> <b>there</b>.
</div>
width
속성이 0으로 설정되어 선이 'Hi' 사이로 래핑됩니다. 그리고 "거기"입니다.
이 상황에 대한 인라인 서식 컨텍스트가 트리로 표시되면 다음과 같습니다.
{
"Line box": {
"Box <span>": {
"Text": "Hi"
}
},
"Line box": {
"Box <b>": {
"Text": "There"
}
},
{
"Text": "."
}
}
플랫 목록은 다음과 같습니다.
- (선 상자, 2)
- (상자 <span>, 1)
- (텍스트 "안녕하세요", 0)
- (선 상자, 3)
- (상자 <b>, 1)
- (텍스트 "there", 0)
- (텍스트 ".", 0)
이 데이터 구조의 많은 소비자가 접근성 API,
및 도형 API(예:
getClientRects
님,
및 contenteditable
.
각 유형마다 요구사항이 다릅니다.
이러한 구성요소는 편의 커서를 통해 플랫 데이터 구조에 액세스합니다.
커서
MoveToNext
, MoveToNextLine
, CursorForChildren
와 같은 API가 있습니다.
이 커서 표현은 다음과 같은 여러 가지 이유로 텍스트 콘텐츠에서 매우 강력합니다.
- 깊이 우선 검색 순서의 반복은 매우 빠릅니다. 이는 캐럿 이동과 유사하기 때문에 매우 자주 사용됩니다. 평면 목록이므로 깊이 우선 검색은 배열 오프셋을 증분할 뿐입니다. 빠른 반복과 메모리 위치를 제공합니다
- 폭넓게 검색을 제공하는 이 기능은 예를 들어 라인 상자와 인라인 상자의 배경을 그리는 중입니다.
- 하위 요소의 수를 알면 다음 동위 요소로 빠르게 이동할 수 있음 (배열 오프셋을 해당 숫자만큼 증가시키기만 하면 됩니다.)
속성 트리
DOM은 요소 (및 텍스트 노드)의 트리이며 CSS는 다양한 스타일을 지정할 수 있습니다.
이는 다음과 같은 4가지 방식으로 표시됩니다.
- Layout: 레이아웃 제약 조건 알고리즘에 대한 입력입니다.
- 페인트: 요소를 칠하고 래스터하는 방법 (하위 요소는 아님)
- 시각적: DOM 하위 트리에 적용되는 래스터/그리기 효과 변환, 필터, 클리핑 등을 예로 들 수 있습니다
- 스크롤: 축 정렬 및 둥근 모서리 포함된 하위 트리의 클리핑 및 스크롤을 지원합니다.
속성 트리는 시각적 효과와 스크롤 효과가 DOM 요소에 적용되는 방식을 설명하는 데이터 구조입니다. 이러한 도구는 어디서, 지정된 DOM 요소입니다. 어떻게 해야 할까요? 시각 효과와 스크롤 효과를 적용하려면 어떤 순서로 GPU 작업을 사용해야 할까요?
웹의 시각 및 스크롤 효과는 매우 복잡합니다. 따라서 속성 트리가 하는 가장 중요한 작업은 이러한 복잡성을 그 구조와 의미를 정확하게 나타내는 단일 데이터 구조로 탈바꿈하고, 동시에 DOM 및 CSS의 나머지 복잡성을 제거합니다. 이를 통해 더욱 자신 있게 합성 및 스크롤 알고리즘을 구현할 수 있습니다. 특히 다음 항목이 중요합니다.
- 오류가 발생하기 쉬운 기하학 및 기타 계산 한곳으로 중앙 집중화될 수 있습니다
- 속성 트리 빌드 및 업데이트의 복잡성 하나의 렌더링 파이프라인 단계로 격리됩니다
- 전체 DOM 상태를 사용하는 것보다 여러 스레드와 프로세스로 속성 트리를 보내는 것이 훨씬 쉽고 빠릅니다. 이를 통해 많은 사용 사례에 사용할 수 있습니다.
- 사용 사례가 많을수록 그 위에 구축된 기하학 캐싱에서 더 많은 이익을 얻을 수 있습니다. 서로를 재사용할 수 있기 때문에 있습니다
RenderingNG는 다음과 같은 여러 용도로 속성 트리를 사용합니다.
- 페인트에서 합성을 분리하고 기본 스레드에서 합성하기
- 최적의 합성 / 그리기 전략 결정
- 측정 IntersectionObserver 정의합니다.
- 오프스크린 요소 및 GPU 텍스처 타일 작업을 방지합니다.
- 페인트 및 래스터를 효율적이고 정확하게 무효화
- 측정 레이아웃 변경 및 코어 웹 바이탈의 최대 콘텐츠 페인트입니다.
모든 웹 문서에는 변환, 클립, 효과, 스크롤이라는 4개의 개별 속성 트리가 있습니다.(*) 변환 트리는 CSS 변환과 스크롤을 나타냅니다. 스크롤 변환은 2D 변환 행렬로 표현됩니다. 클립 트리는 오버플로 클립 효과 트리는 불투명도, 필터, 마스크, 다른 종류의 클립(예: 클립 경로)을 지원합니다. 스크롤 트리는 스크롤에 관한 정보를 나타내며 스크롤하는 방식과 함께 체인됩니다. 컴포지터 스레드에서 스크롤을 실행해야 합니다. 속성 트리의 각 노드는 DOM 요소에 의해 적용된 스크롤 또는 시각 효과를 나타냅니다. 여러 가지 효과가 발생한다면 같은 요소에 대해 각 트리에 둘 이상의 속성 트리 노드가 있을 수 있습니다.
각 트리의 토폴로지는 DOM의 희소 표현과 같습니다. 예를 들어 오버플로 클립이 있는 세 개의 DOM 요소가 있는 경우 세 개의 클립 트리 노드가 있고 클립 트리의 구조는 오버플로 클립 간의 포함 블록 관계를 나타냅니다. 또한 나무 사이에는 연결 고리가 있습니다. 이러한 링크는 상대적인 DOM 계층 구조를 나타내며, 적용 순서가 정해집니다 예를 들어 DOM 요소의 변환이 필터가 있는 다른 DOM 요소 아래에 있으면 필터보다 먼저 변환이 적용됩니다.
각 DOM 요소에는 속성 트리 상태가 있습니다. 이는 4튜플 (변환, 클립, 효과, 스크롤)이며, 는 가장 가까운 상위 클립을 나타냅니다. 해당 요소에 적용되는 효과 트리 노드입니다. 이 정보를 통해 클립 목록을 정확히 알 수 있으므로 매우 편리합니다. 변환 및 효과를 사용하면 어떤 순서로 해야 하는지에 대해 생각해야 합니다. 화면에서 어디에 있는지, 어떻게 그리는지 알려줍니다.
예
(출처)
<html>
<div style="overflow: scroll; width: 100px; height: 100px;">
<iframe style="filter: blur(3px);
transform: rotateZ(1deg);
width: 100px; height: 300px"
id="one" srcdoc="iframe one"></iframe>
</div>
<iframe style="top:200px;
transform: scale(1.1) translateX(200px)" id=two
srcdoc="iframe two"></iframe>
</html>
앞의 예 (소개 부분과 약간 다름)의 경우 생성된 속성 트리의 주요 요소는 다음과 같습니다.
목록 표시 및 페인트 청크
표시 항목에는 하위 수준의 그리기 명령( 여기) 인코더-디코더로 래스터화할 수 있는 Skia. 표시 항목은 일반적으로 테두리나 배경 그리기와 같은 몇 가지 그리기 명령만 있으면 간단합니다. 페인트 트리 워크는 CSS 페인트 순서에 따라 레이아웃 트리 및 관련 프래그먼트를 반복합니다. 표시 항목 목록을 생성합니다.
예를 들면 다음과 같습니다.
<div id="green" style="background:green; width:80px;">
Hello world
</div>
<div id="blue" style="width:100px;
height:100px; background:blue;
position:absolute;
top:0; left:0; z-index:-1;">
</div>
이 HTML 및 CSS는 다음과 같은 표시 목록을 생성합니다. 여기서 각 셀은 표시 항목입니다.
뷰의 배경 | #blue 배경 |
#green 배경 |
인라인 텍스트 #green 개 |
---|---|---|---|
drawRect (크기: 800x600, 색상: 흰색) |
위치 0,0에 크기가 100x100이고 색상이 파란색인 drawRect |
위치 8,8에 크기 80x18이고 색상은 녹색인 drawRect |
위치가 8,8이고 'Hello world' 텍스트가 있는 drawTextBlob |
표시 항목 목록은 맨 뒤 순서로 정렬됩니다. 위의 예에서 녹색 div는 DOM 순서에서 파란색 div 앞에 있습니다. CSS 페인트 순서를 사용하려면 음의 Z-색인 파란색 div 페인트가 녹색 div 앞 (3단계) (4.1단계) 표시 항목은 CSS 페인트 순서 사양의 세부 단계와 대략 일치합니다. 하나의 DOM 요소로 여러 디스플레이 항목이 생길 수 있습니다. #green 에 배경에 대한 표시 항목이 있고 인라인 텍스트에 대한 또 다른 표시 항목이 있는 방식이 이에 해당합니다. 이 세부사항은 CSS 페인트 순서 사양의 전체 복잡성을 나타내는 데 중요합니다. 음의 여백으로 인해 생성되는 인터리브 처리와 같은 예가 있습니다.
<div id="green" style="background:green; width:80px;">
Hello world
</div>
<div id="gray" style="width:35px; height:20px;
background:gray;margin-top:-10px;"></div>
이렇게 하면 다음과 같은 표시 목록이 생성되며, 여기서 각 셀은 표시 항목입니다.
뷰의 배경 | #green 배경 |
#gray 배경 |
인라인 텍스트 #green 개 |
---|---|---|---|
drawRect (크기: 800x600, 색상: 흰색) |
위치 8,8에 크기 80x18이고 색상은 녹색인 drawRect |
drawRect 위치 8,16에 크기 35x20, 색상 회색 |
위치가 8,8이고 'Hello world' 텍스트가 있는 drawTextBlob |
표시 항목 목록은 저장되고 이후 업데이트에서 재사용됩니다. 페인트 트리 워크 중 레이아웃 객체가 변경되지 않은 경우 표시 항목이 이전 목록에서 복사됩니다. 추가적인 최적화는 CSS 페인트 순서 사양의 속성을 사용합니다. 페인트를 원자적으로 스태킹하는 것입니다 스태킹 컨텍스트 내에서 레이아웃 객체가 변경되지 않은 경우 페인트 트리 워크는 스태킹 컨텍스트를 건너뜀 이전 목록에서 표시 항목의 전체 시퀀스를 복사합니다.
현재 속성 트리 상태는 페인트 트리 워크에도 유지됩니다. 표시 항목 목록은 '청크'로 그룹화됩니다. 동일한 속성 트리 상태를 공유하는 디스플레이 항목의 수입니다. 예를 들면 다음과 같습니다.
<div id="scroll" style="background:pink; width:100px;
height:100px; overflow:scroll;
position:absolute; top:0; left:0;">
Hello world
<div id="orange" style="width:75px; height:200px;
background:orange; transform:rotateZ(25deg);">
I'm falling
</div>
</div>
이렇게 하면 다음과 같은 표시 목록이 생성되며, 여기서 각 셀은 표시 항목입니다.
뷰의 배경 | #scroll 배경 |
인라인 텍스트 #scroll 개 |
#orange 배경 |
인라인 텍스트 #orange 개 |
---|---|---|---|---|
drawRect (크기: 800x600, 색상: 흰색) |
위치 0,0에 크기가 100x100이고 색상이 분홍색인 drawRect |
위치가 0,0이고 텍스트가 'Hello world'인 drawTextBlob |
drawRect (위치 0,0에 크기 75x200, 주황색) |
위치가 0,0이고 텍스트가 'I'm falling'인 drawTextBlob |
그러면 변환 속성 트리 및 페인트 청크가 다음과 같이 됩니다 (간략히 하기 위해 단순화).
순서가 지정된 페인트 청크 목록 표시 항목 그룹과 속성 트리 상태 렌더링 파이프라인의 계층화 단계에 대한 입력입니다. 페인트 청크의 전체 목록을 하나의 합성된 레이어로 병합하고 함께 래스터화할 수 있습니다. 그러나 사용자가 스크롤할 때마다 비용이 많이 드는 래스터화가 필요합니다. 합성된 레이어는 각 페인트 청크에 대해 생성될 수 있습니다. 개별적으로 래스터화하여 모든 재래스터화를 방지하지만 GPU 메모리가 빠르게 소진됩니다. 계층화 단계에서는 GPU 메모리 사이에서 절충점을 찾고 상황 변경 시 비용을 절감해야 합니다. 좋은 일반적인 접근 방식은 기본적으로 청크를 병합하는 것입니다. 컴포지터 스레드에서 변경될 것으로 예상되는 속성 트리 상태가 있는 페인트 청크를 병합하지 않아야 합니다. 컴포지터-스레드 스크롤 또는 컴포지터-스레드 변환 애니메이션 등을 사용합니다.
앞의 예에서는 두 개의 합성된 레이어를 생성하는 것이 이상적입니다.
- 그리기 명령을 포함하는 800x600 합성 레이어:
<ph type="x-smartling-placeholder">
- </ph>
drawRect
(크기: 800x600, 색상: 흰색)drawRect
(위치 0,0에 크기 100x100, 색상: 분홍색)
- 그리기 명령을 포함하는 144x224 합성 레이어:
<ph type="x-smartling-placeholder">
- </ph>
- 위치가 0,0이고 'Hello world' 텍스트가 있는
drawTextBlob
- 0,18 번역
rotateZ(25deg)
drawRect
(위치 0,0에 크기 75x200, 주황색)- 위치가 0,0이고 'I'm downing'이라는 텍스트가 있는
drawTextBlob
- 위치가 0,0이고 'Hello world' 텍스트가 있는
사용자가 #scroll
를 스크롤하면
두 번째 합성 레이어가 이동되지만 래스터화는 필요하지 않습니다.
예를 들어 속성 트리에 대한 이전 섹션에서 설명했지만 여섯 개의 페인트 덩어리가 있습니다. (변환, 클립, 효과, 스크롤) 속성 트리 상태와 함께 다음과 같은 특징이 있습니다.
- 문서 배경: 문서 스크롤, 문서 클립, 루트, 문서 스크롤
- div의 가로, 세로, 스크롤 모서리 (세 개의 개별 페인트 청크):
문서 스크롤, 문서 클립,
#one
흐리게 처리, 문서 스크롤 - iframe
#one
:#one
회전, 오버플로 스크롤 클립,#one
블러, div 스크롤 - iframe
#two
:#two
크기, 문서 클립, 루트, 문서 스크롤
컴포지터 프레임: 표면, 렌더링 표면 및 GPU 텍스처 타일
브라우저 및 렌더링 프로세스는 콘텐츠의 래스터화를 관리하고 화면에 표시하기 위해 컴포지터 프레임을 Viz 프로세스에 제출합니다. 래스터화된 콘텐츠를 병합하는 방법을 나타내는 컴포지터 프레임 GPU를 사용하여 효율적으로 그릴 수 있습니다.
카드
이론적으로는 렌더링 프로세스나 브라우저 프로세스 컴포지터가 픽셀을 래스터화하여 렌더기 표시 영역의 전체 크기로 단일 텍스처로 변환하고 이 텍스처를 Viz에 제출합니다. 이를 표시하려면 디스플레이 컴포지터가 픽셀과 단일 텍스처에서 프레임 버퍼의 적절한 위치로 (예: 화면) 그러나 이 컴포지터가 단일 픽셀의 경우 전체 표시 영역을 다시 래스터화하고 새 텍스처를 Viz에 제출해야 합니다.
대신 표시 영역이 타일로 나뉩니다. 별도의 GPU 텍스처 타일은 표시 영역의 일부에 대해 래스터화된 픽셀로 각 타일을 백업합니다. 그러면 렌더러가 개별 타일을 업데이트하거나 기존 타일의 화면에서 위치만 변경하면 됩니다. 예를 들어 웹사이트를 스크롤할 때 기존 타일의 위치가 위로 바뀌고 가끔 페이지 아래쪽에 있는 콘텐츠에 대해 새 카드를 래스터화해야 합니다.
<ph type="x-smartling-placeholder">![타일 4개](https://developer.chrome.google.cn/static/docs/chromium/renderingng-data-structures/image/four-tiles-b115857a2f73.jpg?authuser=19&hl=ko)
쿼드 및 노출 영역
GPU 텍스처 타일은 특별한 종류의 쿼드입니다. 이는 질감의 카테고리 또는 다른 카테고리에 대한 멋진 이름일 뿐입니다. 쿼드는 입력 텍스처를 식별하고 변환 및 시각 효과를 적용하는 방법을 나타냅니다. 예를 들어 일반 콘텐츠 타일에는 타일 그리드에서 x, y 위치를 나타내는 변환이 있습니다.
이러한 래스터화된 타일은 쿼드 목록인 렌더링 패스로 래핑됩니다. 렌더 패스에 픽셀 정보가 포함되어 있지 않습니다. 대신 원하는 픽셀 출력을 생성하기 위해 각 쿼드를 그리는 위치와 방법에 대한 지침이 있습니다. 각 GPU 텍스처 타일에는 그리기 쿼드가 있습니다. 디스플레이 컴포지터는 쿼드 목록을 반복하기만 하면 됩니다. 각각 지정된 시각 효과로 그림을 그리고 렌더 패스에 대해 원하는 픽셀 출력을 생성합니다. 렌더 패스를 위한 그리기 쿼드 합성은 GPU에서 효율적으로 수행할 수 있습니다. 허용되는 시각 효과가 GPU 기능에 직접 매핑되도록 신중하게 선택되기 때문입니다.
래스터화된 타일 외에 추가적인 그리기 쿼드 유형이 있습니다. 예를 들어 텍스처에 의해 전혀 지원되지 않는 단색 그리기 쿼드가 있습니다. 또는 텍스처 그리기 쿼드를 사용합니다.
컴포지터 프레임이 다른 컴포지터 프레임을 삽입할 수도 있습니다. 예를 들어 브라우저 컴포지터는 브라우저 UI를 사용하여 컴포지터 프레임을 생성합니다. 렌더링 컴포지터 콘텐츠가 삽입될 빈 직사각형이 있습니다. 또 다른 예는 사이트 격리 iframe입니다. 이러한 임베딩은 표면을 통해 실행됩니다.
컴포지터가 컴포지터 프레임을 제출할 때 식별자가 수반됩니다. 노출 영역 ID라고 하며, 이를 통해 다른 컴포지터 프레임에 참조로 삽입할 수 있습니다. 특정 표시 경로 ID로 제출된 최신 컴포지터 프레임은 Viz에 의해 저장됩니다. 그러면 다른 컴포지터 프레임이 나중에 표면 그리기 쿼드를 통해 이를 참조할 수 있습니다. Viz는 무엇을 그려야 할지 알고 있습니다. 표면 그리기 쿼드에는 표면 ID만 포함되며 텍스처는 포함되지 않습니다.
중간 렌더링 패스
다수의 필터 또는 고급 혼합 모드와 같은 일부 시각 효과는 중간 텍스처에 두 개 이상의 쿼드를 그려야 합니다. 그런 다음 중간 텍스처는 GPU의 대상 버퍼 (또는 다른 중간 텍스처)로 그려집니다. 할 수 있습니다. 이를 위해 컴포지터 프레임에는 실제로 렌더 패스 목록이 포함됩니다. 항상 루트 렌더 패스가 있으므로 마지막으로 그려지고 해당 대상이 프레임 버퍼에 상응하며, 더 많을 수도 있습니다.
여러 렌더 패스를 사용할 수 있다는 것은 '렌더링 패스'를 사용합니다. 각 패스는 GPU에서 여러 '패스'로 순차적으로 실행되어야 합니다. 반면 단일 패스는 단일 대규모 병렬 GPU 계산에서 완료될 수 있습니다.
집계
여러 컴포지터 프레임이 Viz에 제출됨 화면에 함께 그려야 합니다. 이 작업은 그것들을 단일, 집계된 컴포지터 프레임입니다. 집계는 표면 그리기 쿼드를 지정된 컴포지터 프레임으로 대체합니다. 또한 화면 밖에 있는 불필요한 중간 텍스처나 콘텐츠를 최적화할 수 있는 기회이기도 합니다. 예를 들어 대부분의 경우 사이트 격리 iframe의 컴포지터 프레임은 자체 중간 텍스처가 필요하지 않으며 적절한 그리기 쿼드를 통해 프레임 버퍼로 직접 그릴 수 있습니다. 집계 단계에서는 이러한 최적화와 개별 렌더링 컴포지터가 액세스할 수 없는 전역 지식에 기반하여 적용합니다.
예
다음은 시작 부분의 예를 나타내는 컴포지터 프레임입니다. 확인하세요.
foo.com/index.html
표면: id=0 <ph type="x-smartling-placeholder">- </ph>
- 렌더링 패스 0: 출력에 그립니다.
- 렌더 패스 그리기 쿼드: 3px 블러로 그리고 렌더 패스 0에 클립합니다.
- 렌더 패스 1:
<ph type="x-smartling-placeholder">
- </ph>
#one
iframe의 타일 콘텐츠용 쿼드를 그립니다. 이때 x 및 y 위치를 각각 사용합니다.
- 렌더 패스 1:
<ph type="x-smartling-placeholder">
- 표면 그리기 쿼드: ID 2를 사용하여 배율 및 변환 변환으로 그려짐
- 렌더 패스 그리기 쿼드: 3px 블러로 그리고 렌더 패스 0에 클립합니다.
- 렌더링 패스 0: 출력에 그립니다.
- 브라우저 UI 노출 영역: ID=1
<ph type="x-smartling-placeholder">
- </ph>
- 렌더링 패스 0: 출력에 그립니다.
- 브라우저 UI의 쿼드 그리기 (타일식)
- 렌더링 패스 0: 출력에 그립니다.
bar.com/index.html
노출 영역: ID=2 <ph type="x-smartling-placeholder">- </ph>
- 렌더링 패스 0: 출력에 그립니다.
#two
iframe 콘텐츠의 쿼드를 그립니다. 이때 각 콘텐츠의 x 및 y 위치를 사용합니다.
- 렌더링 패스 0: 출력에 그립니다.
삽화: 우나 크라베츠