이 페이지는 Cloud Translation API를 통해 번역되었습니다.

RenderingNG

차세대 웹 콘텐츠를 위한 준비 완료

Chris Harrelson

저는 Blink의 렌더링 (HTML 및 CSS를 픽셀로 변환)을 담당하는 크리스 해럴슨입니다. 저는 웹에서 우수한 UX를 더 빠르고 쉽고 안정적으로 제공하기 위해 할 수 있는 모든 노력을 기울인다는 취지에서 8년 넘게 웹 성능 렌더링에 집중했습니다. 그 기간 동안 새로운 최첨단 Chromium 렌더링 엔진 아키텍처를 구축하기 위해 어떤 작업을 완료했는지 알려드리게 되어 기쁩니다. 이 곡은 엄청난 사랑의 결실이었습니다. 여러분의 이야기를 들어보시기 바랍니다.

2021년에는 이 아키텍처를 설계, 구축 및 제공하는 과정을 대부분 완료할 예정입니다. 이를 RenderingNG라고 합시다. 이전보다 훨씬 뛰어난 성능을 발휘하는 진정한 차세대 렌더링 아키텍처이기 때문입니다. RenderingNG는 최소 8년 동안 진행되어 왔으며 많은 헌신적인 Chromium 개발자들이 함께 노력한 결과입니다. 빠르고 유연하며 안정적인 반응형 대화형 웹 콘텐츠를 위한 엄청난 잠재력을 제공합니다. 이는 개발자가 신뢰할 수 있는 모든 웹 렌더링 엔진에 대한 새로운 최소 표준을 정의하는 기준이기도 합니다.

이 블로그 게시물은 시리즈의 첫 번째 게시물로, 빌드한 이유, 빌드한 이유, 작동 방식을 설명합니다. 첫 번째 게시물에서는

북극성의 목표입니다.
성공의 피라미드: 작업의 방향을 제시하는 원칙과 이러한 원칙을 실제로 보여주는 사례입니다.
RenderingNG에서 제공하는 기능 및 성능
RenderingNG의 주요 프로젝트 구성요소를 개략적으로 설명합니다.

북극성

RenderingNG의 핵심 목표는 브라우저 엔진 구현과 렌더링 API의 풍부함이 웹 UX의 제한 요소가 되어서는 안 된다는 것입니다.

기능을 불안정하게 만들거나 사이트의 렌더링을 중단시키는 브라우저 버그에 대해 걱정할 필요가 없습니다.

불가사의한 성능 급락 구간이 있어서는 안 됩니다. 또한 누락된 기본 제공 기능을 해결할 필요가 없습니다.

잘 작동해야 합니다.

RenderingNG가 이 북극성의 목표를 향해 커다란 진전을 이루었다고 생각합니다. RenderingNG 이전에는 렌더링 기능을 추가하고 성능을 개선할 수 있었지만 개발자에게 이러한 기능을 안정적으로 제공하는 데 어려움을 겪었고 성능 저하가 많았습니다. 이제 이러한 문제 중 상당수를 체계적으로 해소하고 이전에는 가능하다고 여겨지지 않았던 고급 기능의 차단을 해제하는 아키텍처를 갖추었습니다. 담고 있습니다.

다양한 플랫폼, 기기, 운영체제에서 견고한 핵심 기능을 갖추고 있습니다.
예측 가능하고 안정적인 성능을 제공합니다.
하드웨어 기능 (코어, GPU, 화면 해상도, 화면 재생 빈도, 하위 수준 래스터 API) 사용을 극대화합니다.
표시되는 콘텐츠를 표시하는 데 필요한 작업만 실행합니다.
일반적인 시각 디자인, 애니메이션, 상호작용 디자인 패턴을 기본적으로 지원합니다.
렌더링 비용을 쉽게 관리할 수 있는 개발자 API를 제공합니다.
개발자 부가기능의 렌더링 파이프라인 확장 지점을 제공합니다.
HTML, CSS, 2D 캔버스, 3D 캔버스, 이미지, 동영상, 글꼴 등 모든 콘텐츠를 최적화합니다.

다른 브라우저 렌더링 엔진과 비교

Gecko와 Webkit는 또한 이 블로그 게시물에서 설명한 것과 동일한 아키텍처 기능 대부분을 구현했으며, 경우에 따라 Chromium 이전에도 이러한 기능을 추가했습니다. 매우 좋죠. 더 빠르고 안정적으로 작동하는 브라우저라면 축하해야 할 일이며 실질적인 영향을 미치고 있지만, 궁극적인 목표는 모든 브라우저의 기준을 발전시켜 개발자가 신뢰할 수 있도록 하는 것입니다.

성공의 피라미드

제 철학은 안정성, 확장 가능 성능, 확장성을 차례로 달성하면 성공할 수 있다는 것입니다.

아래쪽에 안정성, 가운데에 성능, 상단에 확장성이라는 라벨이 있는 피라미드

실제 피라미드와 마찬가지로 각 레벨은 그 위 레벨의 견고한 기초를 제공합니다.

안정성

불만이 크게 증가하지 않고 RenderingNG 특성을 추가할 수 있는 방법을 보여주는 스케치

풍부하고 복잡한 사용자 환경을 실현하려면 가장 먼저 필요한 것은 견고한 플랫폼입니다. 핵심 기능과 기반은 올바르게 작동해야 하며 시간이 지나도 계속 작동해야 합니다 이러한 기능들이 잘 구성되어 특이한 사례의 동작이나 버그가 없도록 하는 것도 중요합니다.

특성 추가, 피드백 수렴, 안정성 개선의 순환적 특성을 보여주는 스케치

따라서 안정성은 RenderingNG에서 가장 중요한 단 하나의 요소입니다. 그리고 안정성은 좋은 테스트, 품질 피드백 루프, 측정항목, 소프트웨어 설계 패턴의 결과입니다.

신뢰성이 얼마나 중요한지 파악하기 위해 지난 8년의 대부분은 이 부분만 완료했습니다. 먼저 Google은 시스템에 관한 심층적인 지식을 구축했습니다. 버그 신고를 통해 취약점이 있는 부분을 학습하고 이를 수정하고, 포괄적인 테스트를 부트스트랩하고, 사이트의 성능 요구사항과 Chromium 성능의 제한사항을 이해했습니다. 그런 다음 주요 설계 패턴과 데이터 구조를 신중하고 점진적으로 설계하고 배포했습니다. 비로소 우리는 반응형 디자인, 확장성, 렌더링 맞춤설정을 위한 진정한 차세대 프리미티브를 추가할 준비가 되었습니다.

시간 경과에 따라 향상되는 안정성, 성능, 확장성을 보여주는 스케치 그래프

그렇다고 해서 그 기간 동안 Chromium에서 개선된 사항이 없다는 것은 아닙니다. 오히려 반대입니다. 지난 몇 년 동안 각 개선사항을 단계별로 리팩터링하고 출시하면서 안정성과 성능이 꾸준하고 지속적으로 향상되었습니다.

테스트 및 측정항목

지난 8년 동안 Google은 수만 개의 단위, 성능, 통합 테스트를 추가했습니다. 또한 Google은 Chromium의 렌더링이 로컬 테스트, 성능 벤치마크, 실제 사이트(실제 사용자 및 기기)에서 실제로 작동하는 방식의 여러 측면을 측정하는 포괄적인 측정항목을 개발했습니다.

그러나 RenderingNG (또는 다른 브라우저의 렌더링 엔진)가 아무리 훌륭하더라도 브라우저 간 동작 차이가 많거나 버그가 많으면 웹용으로 개발하기가 쉽지 않습니다. 이를 해결하기 위해 Google은 웹 플랫폼 테스트의 사용을 최대화합니다. 각 테스트는 모든 브라우저가 통과해야 하는 웹 플랫폼의 사용 패턴을 확인합니다. 또한 시간이 지남에 따라 더 많은 테스트를 통과하고 핵심 호환성이 향상되도록 측정항목을 면밀히 모니터링합니다.

웹 플랫폼 테스트는 공동의 노력으로 진행됩니다. 예를 들어 Chromium 엔지니어는 CSS 기능에 관한 총 WPT 테스트 중 약 10% 만 추가했습니다. 나머지 브라우저 공급업체, 독립 참여자, 사양 작성자가 나머지에 기여합니다. 상호 운용 가능한 웹을 만들려면 하나의 마을이 필요합니다!

다른 엔진으로 통과하는 테스트 — wpt.fyi/compat2021부터 핵심 기능에 대한 WPT 통과율 측정

좋은 소프트웨어 디자인 패턴

코드를 이해하기 쉽고 버그 가능성을 최소화하는 방식으로 설계하면 고품질 소프트웨어를 안정적으로 제공할 수 있습니다. 이후 블로그 게시물에서 RenderingNG의 소프트웨어 설계에 대해 더 많은 내용을 다루겠습니다.

확장 가능한 성능

속도, 메모리, 전력 사용 차원에서 우수한 성능을 달성하는 것이 RenderingNG에서 가장 중요한 측면입니다. Google은 기기의 안정성을 저해하지 않으면서 모든 웹사이트와의 상호작용이 원활하고 반응하기를 바랍니다.

하지만 성능뿐만 아니라 확장 가능한 성능, 즉 저사양 및 고급형 머신과 여러 OS 플랫폼에서 안정적으로 잘 실행되는 아키텍처를 추구합니다. 이를 수직 확장이라고 합니다. 즉, 하드웨어 기기가 달성할 수 있는 모든 이점을 활용하고 축소하여 효율성을 극대화하고 필요할 때 시스템에 대한 수요를 줄입니다.

이를 위해서는 캐싱, 성능 격리, GPU 하드웨어 가속을 최대한 활용해야 했습니다. 하나씩 차례로 살펴보겠습니다. 구체적으로 설명하기 위해 웹페이지에서 매우 중요한 한 가지 상호작용인 스크롤의 실적에 각 요소가 어떻게 기여하는지 생각해 보겠습니다.

캐싱

웹과 같은 동적 대화형 UI 플랫폼에서 캐싱은 성능을 크게 향상하는 가장 중요한 단일 방법입니다. 브라우저에서 가장 잘 알려진 캐싱 유형은 HTTP 캐시이지만, 렌더링에는 많은 캐시도 있습니다. 스크롤에 가장 중요한 캐시는 캐시된 GPU 텍스처 및 표시 목록으로, 이를 통해 배터리 소모를 최소화하고 다양한 기기에서 잘 작동하는 동시에 스크롤 속도를 높일 수 있습니다.

캐싱은 스크롤 시 배터리 수명과 애니메이션 프레임 속도에 도움이 되지만, 기본 스레드에서 성능 격리가 차단 해제된다는 점이 더 중요합니다.

성능 격리

최신 데스크톱 컴퓨터에서는 백그라운드 애플리케이션으로 인해 작업 중인 작업의 속도가 느려질까 봐 걱정할 필요가 없습니다. 이는 선점형 멀티태스킹, 즉 성능 격리의 일종으로, 독립적인 작업이 서로 느려지지 않도록 하기 때문입니다.

웹에서 성능 격리의 가장 좋은 예는 스크롤입니다. 느린 자바스크립트가 많은 웹사이트에서도 스크롤이 매우 원활하게 작동할 수 있습니다. 스크롤이 자바스크립트 및 레이아웃 스레드에 종속되지 않아도 되는 다른 스레드에서 실행되기 때문입니다. Google은 단순히 표시 목록을 뛰어넘어 더 복잡한 상황에 이르는 캐싱을 통해 가능한 모든 스크롤이 스레드되도록 하기 위해 RenderingNG에 많은 노력을 쏟고 있습니다. 고정 및 고정 위치 요소를 나타내는 코드, 패시브 이벤트 리스너, 고품질 텍스트 렌더링 등을 예로 들 수 있습니다.

Sketch에서는 JavaScript가 매우 느릴 때도 RenderingNG 성능이 안정적으로 유지되는 것을 볼 수 있습니다.

GPU 가속

GPU를 사용하면 픽셀을 생성하고 화면에 그리는 속도가 현저히 빨라집니다. 대부분의 경우 모든 픽셀을 다른 모든 픽셀과 병렬로 그릴 수 있어 속도가 크게 향상됩니다. RenderingNG의 핵심 구성요소는 GPU 래스터이며 어디에나 그리기입니다. 모든 플랫폼과 기기에서 GPU를 사용하여 웹 콘텐츠의 렌더링과 애니메이션 처리 속도를 높입니다. 이는 특히 기기의 다른 부분보다 GPU 성능이 뛰어난 저사양 기기나 고급형 기기에서 중요합니다.

Sketch에서는 RenderingNG에서 성능이 그다지 크게 저하되지 않음을 보여줍니다.

확장성: 작업에 적합한 도구

안정성과 확장 가능한 성능을 확보했다면 이제 Google은 다양한 도구를 기반으로 빌드하여 개발자가 HTML, CSS, 캔버스의 기본 제공 부분을 확장하고 이러한 어렵게 얻은 성능과 안정성을 희생하지 않는 방식으로 확장할 준비가 되었습니다.

여기에는 반응형 디자인, 프로그레시브 렌더링, 부드러움 및 응답성, 스레드 렌더링의 고급 사용 사례를 위한 내장 및 JavaScript 노출 API가 포함됩니다.

Chromium에서 지원하는 다음과 같은 오픈 웹 API는 RenderingNG를 통해 가능했으며 이전에는 불가능했던 것으로 간주되었습니다.

이러한 모든 기능은 개방형 사양을 기반으로 개발되었으며 다른 브라우저의 엔지니어, 전문가, 웹 개발자 등 개방형 웹 파트너와의 협업을 통해 개발되었습니다. 이어지는 블로그 게시물에서는 이러한 각 항목을 자세히 살펴보고 RenderingNG를 통해 이를 가능하게 만드는 방법을 설명합니다.

content- visibility: 사이트에서 화면 밖 콘텐츠의 렌더링 작업과 현재 표시되지 않는 단일 페이지 애플리케이션 뷰의 캐시 렌더링을 쉽게 방지할 수 있습니다.
OffscreenCanvas: 안정적으로 우수한 성능을 위해 캔버스 렌더링(2D 캔버스 API 및 WebGL 모두)을 자체 스레드에서 실행할 수 있도록 합니다. 이 프로젝트는 웹의 또 다른 주요 성과로, JavaScript (또는 WebAssembly!)가 여러 스레드에서 단일 웹페이지 문서를 렌더링할 수 있게 하는 최초의 웹 API입니다.
컨테이너 쿼리: 단일 구성요소가 반응형으로 자체 배치하여 전체 플러그 앤 플레이 구성요소 (현재 실험용 구현)의 차단을 해제할 수 있습니다.
출처 격리: 사이트에서 iframe 간에 더 많은 성능 격리를 사용하도록 선택할 수 있습니다.
오프 메인 스레드 페인트 Worklet: 개발자는 컴포지터 스레드에서 실행되는 코드를 사용하여 요소가 페인트되는 방식을 확장할 수 있습니다.

명시적인 웹 API 외에도 RenderingNG를 통해 모든 사이트에 도움이 되는 매우 중요한 몇 가지 '자동 기능'을 제공할 수 있었습니다.

사이트 격리: 더 나은 보안 및 성능 격리를 위해 여러 CPU 프로세스에 교차 출처 iframe을 배치합니다.
Vulkan, D3D12, Metal: OpenGL보다 GPU를 더 효율적으로 사용하는 하위 수준 API를 활용합니다.
더욱 합성된 애니메이션: SVG, 배경 색상

RenderingNG에 의해 차단 해제될 예정인 추가 기능은 다음과 같습니다.

RenderingNG를 구성하는 주요 프로젝트

다음은 RenderingNG 내의 주요 프로젝트 목록입니다. 이어지는 블로그 게시물에서 각 기능을 자세히 살펴볼 예정입니다.

CompositeAfterPaint

합성을 스타일, 레이아웃 및 페인트와 분리하여 안정성과 예측 가능한 성능을 크게 개선하고, 처리량을 늘리며, 성능 저하 없이 메모리를 더 적게 사용합니다. 2014년에 시작되어 올해 안에 마무리될 예정입니다.

연도	진행률
2015	디스플레이 목록을 배송합니다.
2017	새 무효화를 배송합니다.
2018	배송 속성 트리 1부.
2019	배송 속성 트리 2부.
2021	프로젝트 배송이 완료되었습니다.

LayoutNG

안정성과 예측 가능한 성능을 크게 향상시키기 위해 모든 레이아웃 알고리즘을 처음부터 다시 작성합니다. 2016년에 시작되어 올해 완료될 예정입니다

연도	진행률
2019	배송 차단 흐름
2020	유연하게 편집하세요.
2021	나머지는 모두 발송합니다.

BlinkNG

Blink 렌더링 엔진을 체계적으로 정리하고 깔끔하게 분리된 파이프라인 단계로 리팩터링합니다. 이를 통해 캐싱 개선, 안정성, 재진입 또는 지연 렌더링 기능(예: 콘텐츠 공개 상태 및 컨테이너 쿼리)이 향상됩니다. 2014년에 시작되어 점차적으로 개선되어 계속 이어지고 있습니다. 이 작업은 2021년에 완료될 예정입니다.

어디서나 가능한 GPU 가속

모든 플랫폼에서 GPU 래스터화, 그리기 및 애니메이션을 항상 출시하기 위한 장기적인 노력 GPU 가속은 모든 픽셀을 병렬로 처리할 수 있으므로 대부분의 콘텐츠에서 속도가 크게 향상됩니다. 여전히 GPU를 사용하는 경향이 있는 저사양 기기에서 성능을 개선하는 데도 효과적인 방법입니다. 2014년에 시작되어 2020년에 완료되었습니다.

연도	진행률
2014	캔버스 지원 Android의 선택사항 콘텐츠에서 배송됩니다.
2016	Mac에서 배송을 탭합니다.
2017	GPU는 Android 페이지 조회수의 60% 이상에서 사용됩니다.
2018	Windows, ChromeOS, Android Go에 제공됩니다.
2019	스레드된 GPU 래스터화
2020	나머지 Android 콘텐츠를 전송합니다.

스레드 스크롤, 애니메이션, 디코딩

모든 스크롤, 레이아웃을 유도하지 않는 애니메이션, 이미지 디코딩을 기본 스레드에서 이동시키기 위한 장기적인 노력 2011년에 시작되어 현재 진행 중입니다.

연도	진행률
2011	스레드 스크롤 및 애니메이션을 초기에 지원합니다.
2015	레이어 스쿼싱
2016	범용 오버플로 스크롤.
2017	이미지가 컴포지터 스레드에서 디코딩됩니다.
2018	컴포지터 스레드의 이미지 애니메이션
2020	항상 고정 위치를 합성합니다.
2021	변환 애니메이션, SVG 애니메이션의 비율

시각화

Chromium의 중앙 집중식 래스터 및 그리기 프로세스로 처리량을 늘리고 메모리를 최적화하며 하드웨어 기능을 최적으로 사용할 수 있습니다. 또한 사이트 격리를 차단 해제하고 브라우저 UI 렌더링에서 렌더링 파이프라인을 분리하는 것과 같은 다른 이점도 웹 개발자에게는 덜 보이지만 사용자에게는 아주 잘 보입니다. 2016년에 시작되어 2021년에 완료될 예정입니다.

연도	진행률
2018	OOP-R은 Android, Mac, Windows에 기본 제공됩니다.
2019	OOP-D 발송됨 OOP-R은 모든 지역에 배송됩니다 (캔버스 제외). Linux에서 SkiaRenderer가 출시되었습니다.
2020	SkiaRenderer는 Windows 및 Android에 출시되었습니다. Vulkan은 Android에 기본 제공됩니다.
2021	SkiaRenderer는 Mac에 출시되었으며 ChromeOS도 곧 지원될 예정입니다.

위 차트에 나온 용어의 정의:

OOP-D: 프로세스 외부 디스플레이 컴포지터. 디스플레이 합성은 OS 컴포지터와 동일한 종류의 활동입니다. 외부 프로세스란 웹페이지의 렌더링 프로세스나 브라우저 UI 프로세스가 아닌 Viz 프로세스에서 작업을 수행하는 것을 의미합니다.
OOP-R: 프로세스 외부 래스터입니다. 래스터가 표시 목록을 픽셀로 변환합니다. 외부 프로세스란 웹페이지의 렌더링 프로세스가 아닌 Viz 프로세스에서 작업을 수행하는 것을 의미합니다.
SkiaRenderer: Vulkan, D3D12 또는 Metal과 같은 다양한 기본 GPU API에서 실행을 지원할 수 있는 새로운 디스플레이 컴포지터 구현입니다.

스레드 및 가속 캔버스 렌더링

이 프로젝트는 OffscreenCanvas를 가능하게 한 아키텍처의 조각을 제시한 프로젝트입니다. 2015년에 시작되어 2021년에 완료될 예정입니다.

연도	진행률
2018	OffscreenCanvas 배송
2019	ImageBitmapRenderingContext를 배송합니다.
2021	OOP-R을 발송합니다.

VideoNG

웹에서 효율적이고 신뢰할 수 있는 고품질 동영상 재생을 제공하기 위한 장기적인 노력

연도	진행률
2014	Mojo 기반 렌더링 프레임워크를 도입했습니다.
2015	더 원활한 동영상 렌더링을 위해 Project Butter 및 동영상 오버레이가 배송되었습니다.
2016	통합 Android 및 데스크톱 디코딩 및 렌더링 파이프라인이 출시되었습니다.
2017	HDR 및 색상 보정 동영상 렌더링이 출시되었습니다.
2018	Mojo 기반 동영상 디코딩 파이프라인이 출시되었습니다.
2019	배송된 노출 영역 기반 동영상 렌더링 파이프라인
2021	ChromeOS에 4K 보호된 콘텐츠 렌더링 지원이 추가되었습니다.

위 차트에 나온 용어의 정의:

모조: Chromium용 차세대 IPC 하위 시스템
표시 경로: Viz 프로젝트 설계의 일부인 개념

결론

웹과 Chromium에서의 렌더링 속도에 엄청난 흥분을 일으켰습니다. RenderingNG의 견고한 기반을 토대로 구축하면서 앞으로 몇 년 동안은 속도가 계속 빨라질 것으로 예상됩니다.

앞으로 더 많은 게시물을 통해 새로운 아키텍처, 어떻게 만들어졌는지, 어떻게 작동하는지도 자세히 다루도록 하겠습니다.

기기 사진 출처: 에릭 솔하임, Unsplash

일러스트레이션: 우나 크라베츠(Una Kravets)