이 글은 아래 원문을 번역한 글로 의역이 있을 수 있습니다. 정확한 의미를 파악하고 싶으신 분은 원문을 참고해주시기 바랍니다.
원문: https://developer.chrome.com/blog/renderingng/
저작권 정보: https://developers.google.com/terms/site-policies
이 글은 크롬 렌더링 엔진에 있는 시리즈의 일부분이다. 나머지 시리즈에서 렌더링NG 아키텍처, 주요 데이터 구조, VideoNG 및 LayoutNG에 대해 자세히 알아보십시오.
나는 Chris Harrelson이고, Blink의 Rendering (HTML과 CSS를 픽셀로 변환)의 엔지니어링 리더 입니다. 나는 웹에서 우수한 UX를 더 빠르고, 더 쉽고, 더 신뢰할 수 있게 전달하기 위해 내가 할 수 있는 모든 것을 한다는 개인적인 목표를 가지고 8년 넘게 웹에서 성능을 렌더링하는 문제에 깊이 빠져 있었습니다. 나는 우리가 새로운 최첨단 크롬 렌더링 엔진 아키텍처를 구축하기 위해 그 시간 동안 무엇을 했는지를 알려드리게 되어 기쁩니다. 이것을 성취하는 것은 엄청난 사랑의 노력이었고, 나는 당신이 그것에 대해 듣는 것을 즐겼으면 좋겠습니다!
2021년에는 이 구조를 설계, 제작, 출하하는 과정을 마무리할 것입니다. 이는 진정한 차세대 렌더링 아키텍처로 이전에 비해 월등히 뛰어나기 때문에 이를 렌더링NG라고 부릅시다. 렌더링NG는 최소 8년 동안 진행되어 왔으며, 많은 크로미움 개발자들의 집합적인 작업을 나타냅니다. 그것은 차세대의 빠르고, 유동적이고, 신뢰할 수 있고, 응답성이 높고, 상호작용적인 웹 콘텐트를 위한 엄청난 양의 잠재력을 제공합니다. 그것은 또한 개발자들이 의존할 수 있는 모든 웹 렌더링 엔진에 대한 새로운 최소 표준을 정의한다고 나는 믿습니다.
이 게시물은 시리즈 중 첫 번째로 우리가 무엇을 만들었는지, 왜 만들었는지, 어떻게 작동하는지 설명해 줄 겁니다. 이 첫 번째 게시물에서 나는 다음과 같이 시작합니다.
- 우리의 커다란 목표.
- 성공의 피라미드: 우리의 일을 이끄는 원칙들, 그리고 그 원칙들의 실제적인 예들.
- 렌더링NG가 가능하게 하는 특징과 기능.
- 렌더링NG의 주요 프로젝트 구성요소에 대한 개략적인 개요.
North star
RenderingNG의 목표는 브라우저 엔진 구현과 그 렌더링 API의 풍부함이 웹 상에서 UX의 제한 요인이 되어서는 안 된다는 것이다.
당신은 브라우저 버그가 기능을 신뢰할 수 없게 만들거나 사이트의 렌더링을 손상시키는 것에 대해 걱정할 필요가 없다.
미스테리한퍼포먼스 절벽이 있어서는 안 된다. 그리고, 당신은 누락된 내장 기능들에 대해 작업할 필요가 없다.
그것은 그냥 동작할거야.
나는 렌더링NG가 이 목표를 향한 큰 진전이라고 믿는다. 렌더링NG 이전에는 렌더링 기능을 추가하고 성능을 향상할 수 있었지만, 개발자에게 안정적인 기능을 제공하기 위해 노력했고, 성능 저하도 많았다. 이제 우리는 그러한 많은 문제들을 체계적으로 제한하고 또한 이전에는 실현 가능하다고 여겨지지 않았던 진보된 특징들을 차단하지 않는 구조를 가지고 있다.
- 다양한 플랫폼, 장치 및 운영 체제 조합에 견고한 핵심 기능 보유
- 예측 가능하고 신뢰할 수 있는 성능
- 하드웨어 기능(코어, GPU, 화면 해상도, 새로 고침 빈도, 로우 레벨 래스터 API)의 사용 극대화
- 눈에 보이는 콘텐츠를 표시하는 데 필요한 작업만 수행한다.
- 공통 시각 디자인, 애니메이션 및 상호작용 디자인 패턴에 대한 내장된 지원 기능
- 개발자 API를 제공하여 렌더링 비용을 쉽게 관리
- 개발자 추가 기능에 대한 렌더링 파이프라인 확장 지점 제공
- 모든 컨텐츠 최적화 - HTML, CSS, 2D 캔버스, 3D 캔버스, 이미지, 비디오 및 글꼴.
다른 브라우저 렌더링 엔진과 비교
Gecko와 Webkit 역시 이들 블로그 게시물에 기술된 것과 거의 동일한 아키텍쳐 특징을 대부분 구현했으며, 경우에 따라서는 크롬 이전에 추가하기도 했다. 대단하다! 어떤 하나의 브라우저가 더 빠르고 더 신뢰할 수 있게 되면 실질적인 영향을 미치지만, 궁극적인 목표는 모든 브라우저에 대한 기준을 발전시켜 개발자들이 그것에 의존할 수 있도록 하는 것이다.
성공의 피라미드
나의 철학은 성공은 먼저 신뢰도를 달성한 다음 확장 가능한 성능, 그리고 마지막으로 확장성을 달성한 결과라는 것이다.
실제 피라미드와 마찬가지로, 각 레벨은 위 레벨에 대한 필수적으로 견고한 기초를 제공한다.
신뢰성
풍부하고 복잡한 사용자 경험이 조금이라도 가능하려면, 우리에게 가장 먼저 필요한 것은 견고한 플랫폼이다. 코어 기능과 밑받침은 올바르게 작동해야 하며, 시간이 지나도 계속 작동해야 한다. 그리고 그러한 특징들이 잘 구성되고 이상한 엣지-케이스 동작이나 버그를 갖지 않는 것도 마찬가지로 중요하다.
이러한 이유로, 신뢰성은 렌더링NG에서 가장 중요한 한 부분이다. 그리고 신뢰성은 우수한 테스트, 품질 피드백 루프, 측정 기준 및 소프트웨어 설계 패턴의 결과물이다.
내가 신뢰성이 얼마나 중요하다고 생각하는지 알기 위해 우리는 지난 8년 동안 대부분 이 부분만 고려하면서 보냈다. 첫째, 우리는 시스템에 대한 깊은 지식을 쌓았다. 즉, 취약점이 어디에 있는지 버그 리포트에서 학습하여 이를 수정하고, 포괄적인 테스트를 진행하며, 현장의 성능 요구와 크롬 성능의 한계를 이해했다. 그런 다음, 핵심 설계 패턴과 데이터 구조를 신중하고 점진적으로 설계하고 롤아웃했다. 그때서야 우리는 렌더링의 반응성 설계, 확장성 및 맞춤화를 위한 진정한 차세대 원시 요소(primitives)를 추가할 준비가 되었다.
이것은 크롬에서 그 시간 동안 개선된 것이 아무것도 없었다는 말은 아니다. 사실, 그 반대야! 그 해에는 우리가 각 개선 사항을 단계별로 리팩터링하고 롤아웃함에 따라 신뢰성과 성능의 지속적이고 지속적인 증가를 보였다.
테스트 및 메트릭
지난 8년 동안 수만 개의 유닛과 성능, 통합 테스트를 추가했다. 또한 크롬 렌더링이 실제 사용자와 장치를 사용하여 로컬 테스트, 성능 벤치마크 및 실제 현장에서 어떻게 동작하는지에 대한 여러 측면을 측정하는 종합적인 메트릭스를 개발했다.
그러나 렌더링NG(또는 다른 브라우저의 렌더링 엔진)가 아무리 훌륭하더라도, 브라우저 간의 동작이나 버그가 많으면 웹을 위해 개발하기가 여전히 쉽지 않을 것이다. 이 문제를 해결하기 위해 우리는 또한 웹 플랫폼 테스트의 사용을 최대화한다. 이러한 각각의 테스트는 모든 브라우저가 통과하고자 하는 웹 플랫폼의 사용 패턴을 검증한다. 우리는 또한 시간이 지남에 따라 더 많은 테스트를 통과하고 핵심 호환성을 증가시키기 위한 측정 기준을 면밀히 감시한다.
웹 플랫폼 테스트는 공동 작업이다. 예를 들어 Chromium 엔지니어는 CSS의 기능에 대한 총 WPT 테스트의 약 10%만 추가했으며, 다른 브라우저 벤더, 독립 기여자 및 사양 작성자는 나머지를 기여한다. 상호운용 가능한 web을 만들려면 여러 사람들이 필요하다!
우수한 소프트웨어 설계 패턴
양질의 소프트웨어를 안정적으로 제공하는 것은 코드를 이해하기 쉽고 버그 발생 가능성을 최소화하는 방식으로 설계할 경우 훨씬 더 쉬워진다. 우리는 후속 블로그 게시물에서 렌더링NG의 소프트웨어 디자인에 대해 더 많은 것을 말할 것이다.
확장 가능한 성능
속도, 메모리 및 전력 사용이 우수한 성능을 달성하는 것은 렌더링NG의 가장 중요한 측면이다. 우리는 모든 웹 사이트와의 상호작용이 원활하고 대응적이면서도 기기의 안정성을 희생시키지 않기를 바란다.
그러나 우리는 단순히 성능을 원하는 것이 아니라 확장 가능한 성능, 즉 로우엔드 및 하이엔드 머신에서, 그리고 OS 플랫폼 전반에 걸쳐 안정적으로 성능을 발휘하는 아키텍처를 원한다. 하드웨어 장치가 달성할 수 있는 모든 이점을 활용하여 효율성을 극대화하고 필요에 따라 시스템에 대한 수요를 줄이는 스케일업(Scaling up)이라 부른다.
이를 위해 캐싱, 성능 격리, GPU 하드웨어 가속화를 최대한 활용할 필요가 있었다. 각자 차례대로 생각해 봅시다. 그리고 그것을 구체적으로 설명하기 위해, 웹페이지의 매우 중요한 상호작용인 스크롤링의 수행에 각자가 어떻게 기여하는지에 대해 생각해 봅시다.
캐싱
웹과 같은 동적 대화형 UI 플랫폼에서 캐싱은 성능을 획기적으로 향상시키는 가장 중요한 단일 방법이다. 브라우저에서 가장 잘 알려진 캐싱의 종류는 HTTP 캐시지만 렌더링에도 캐시가 많다. 스크롤에 가장 중요한 캐시는 캐시된 GPU 텍스처와 디스플레이 목록으로, 배터리 방전을 최소화하고 다양한 장치에서 잘 작동하면서 스크롤이 매우 빠를 수 있다.
캐싱은 스크롤을 위한 배터리 수명과 애니메이션 프레임률을 돕지만, 더욱 중요한 것은 메인 스레드에서의 성능 격리를 차단하지 않는다는 점이다.
성능 격리
현대의 데스크톱 컴퓨터에서는 백그라운드 애플리케이션이 작업 중인 애플리케이션의 속도를 늦추는 것에 대해 걱정할 필요가 없다. 그 이유는 선제적인 멀티태스킹 때문인데, 이는 결국 성능 격리의 한 형태인 즉, 독립적인 업무들이 서로 속도를 늦추지 않도록 하는 것이다.
웹에서 성능 격리의 가장 좋은 예는 스크롤이다. 느린 자바스크립트가 많은 웹사이트에서도 스크롤은 자바스크립트와 레이아웃 스레드에 의존하지 않아도 되는 다른 스레드에서 실행되기 때문에 매우 매끄러울 수 있다. 단순히 표시 목록을 넘어 보다 복잡한 상황에 이르는 캐싱을 통해 가능한 모든 스크롤이 스레딩되도록 렌더링NG에 많은 노력을 기울였다. 고정 및 고정 위치 요소를 나타내는 코드, 수동 이벤트 수신기, 고품질 텍스트 렌더링 등이 그 예다.
GPU 가속도
GPU는 픽셀 생성과 화면 그리기를 획기적으로 빠르게 만든다. 많은 경우 모든 픽셀을 다른 픽셀과 병렬로 그릴 수 있기 때문에 엄청난 속도 증가를 초래한다. 렌더링NG의 핵심 구성 요소는 GPU 래스터와 드로잉이다. 이것은 모든 플랫폼과 모든 장치의 GPU를 사용하여 웹 콘텐츠의 렌더링과 애니메이션을 초고속화한다. 이는 특히 낮은 수준의 기기나 매우 높은 수준의 기기에서는 중요하다. 이 기기에는 다른 부분보다 훨씬 더 뛰어난 GPU를 가지고 있는 경우가 많다.
확장성: 작업에 적합한 도구
일단 안정성과 확장 가능한 성능을 확보하게 되면, 개발자들이 HTML, CSS 및 캔버스의 내장 부품을 확장하고 어렵게 얻은 성능과 안정성을 희생시키지 않는 방식으로 확장할 수 있는 다양한 툴을 구축할 준비가 되어 있다.
여기에는 응답 설계(responsive design), 점진적 렌더링, 부드러움과 응답성, 스레드 렌더링의 고급 사용 사례를 위한 내장 및 JavaScript API가 포함된다.
크롬이 지원하는 다음과 같은 오픈 웹 API는 렌더링NG에 의해 가능하게 되었고, 이전에는 실현 불가능한 것으로 간주되었다.
이들 모두는 개방형 사양과 다른 브라우저의 엔지니어, 전문가, 웹 개발자 등 오픈 웹 파트너와의 협업으로 개발되었다. 후속 블로그 게시물에서는 이러한 각각의 내용에 대해 살펴보고 렌더링NG가 어떻게 이들을 가능하게 하는지에 대해 설명할 것이다.
- content-visibility: 사이트는 오프스크린 콘텐츠에 대한 렌더링 작업과 현재 사용되지 않는 단일 페이지 응용프로그램(SPA) 뷰에 대한 캐시 렌더링을 쉽게 피할 수 있다.
- OffscreenCanvas: 캔버스 렌더링(2D 캔버스 API와 WebGL 모두)이 자체 스레드에서 실행되어 안정적으로 우수한 성능을 발휘할 수 있도록 한다. 이 프로젝트는 또한 웹의 또 다른 중요한 이정표로서, JavaScript(또는 WebAssembly!)가 여러 스레드에서 단일 웹 페이지 문서를 렌더링할 수 있는 최초의 웹 API이다.
- Container queries: 단일 구성요소가 대응적으로 배치되어 플러그 앤 플레이 구성요소의 전체 영역을 차단할 수 있음(현재 실험 구현).
- Origin isolation: 사이트는 iframes 간의 성능 격리를 개선할 수 있다.
- Off-main-thread paint worklets:컴포지터 스레드에서 실행되는 코드를 사용하여 개발자에게 요소가 그려지는 방법을 확장할 수 있는 방법을 제공한다.
RenderingNG는 명시적인 웹 API 외에도 다음과 같은 매우 중요한 몇 가지 "자동 기능"을 모든 사이트에 제공할 수 있도록 했다.
- Site Isolation: 보안 및 성능 격리를 개선하기 위해 서로 다른 CPU 프로세스에 서로 다른 원본 iframe을 배치하십시오.
- Vulkan, D3D12, and Metal: OpenGL보다 GPU를 더 효율적으로 사용하는lower-level API를 활용한다.
- 더 복합적인 애니메이션:SVG,배경색
RenderingNG에 의해 차단되지 않은 추가 기능에는 다음이 포함된다.
- 스크롤 링크된 애니메이션.
- 숨겨져 있지만 검색 가능하고 액세스 가능한 DOM.
- 공유 요소 전환.
- 사용자 지정 레이아웃.
- 오프메인 스레드 합성, 디커플링 스레드 및 컴포지팅.
렌더링NG를 구성하는 주요 프로젝트
아래는 렌더링NG 내의 주요 프로젝트 목록이다. 후속 블로그 게시물은 각각의 블로그에 깊이 들어갈 것이다.
CompositeAfterPaint
스타일, 레이아웃 및 페인트에서 컴포지팅을 분리하여, 씬 향상된 안정성과 예측 가능한 성능, 향상된 처리량 및 성능 저하 없이 적은 메모리 사용이 가능합니다. 그것은 2014년에 시작되었고 올해 끝날 것이다.
| 연도 | 과정 |
| 2015 | Ship display lists. |
| 2017 | Ship new invalidation. |
| 2018 | Ship property trees part 1. |
| 2019 | Ship property trees part 2. |
| 2021 | Ship SVG. |
LayoutNG
모든 배치 알고리즘의 기초적인 재작성을 통해 신뢰성이 크게 향상되고 예측 가능한 성능이 향상됨. 2016년에 시작되어 올해 마칠 예정이다.
| 연도 | 과정 |
| 2019 | Ship block flow. |
| 2020 | Ship flex, editing. |
| 2021 | Ship everything else. |
BlinkNG
깨끗하게 분리된 파이프라인 단계에서 Blink 렌더링 엔진을 체계적으로 정리 및 리팩터링합니다.. 이를 통해 캐싱 성능 향상, 신뢰성 향상, 콘텐츠 가시성 및 컨테이너 조회와 같은 재입고(re-entrant) 또는 지연 렌더링 기능이 가능하다. 그것은 2014년에 시작되었고 점진적으로 개선되었고 그 이후로 계속 진행되어 왔다. 그것은 2021년에 완성될 것이다.
어디서나 GPU 가속
모든 플랫폼에서 항상 GPU rasterization, 드로잉 및 애니메이션을 구현하기 위한 장기적인 노력을 해왔다. GPU 가속은 모든 픽셀을 병렬로 처리할 수 있기 때문에 대부분의 콘텐츠에 대해 엄청난 속도를 제공한다. 아직 GPU가 남아 있는 경향이 있는 보급형 기기의 성능향상을 위한 효과적인 방법이기도 하다.2014년에 시작해 2020년에 완성했다.
| 연도 | 과정 |
| 2014 | Canvas support. Shipped on opt-in content on Android. |
| 2016 | Ship on Mac. |
| 2017 | GPU is used on over 60% of Android page views. |
| 2018 | Ship on Windows, ChromeOS, and Android Go. |
| 2019 | Threaded GPU rasterization. |
| 2020 | Ship remaining Android content. |
스레드 스크롤, 애니메이션 및 디코딩
모든 스크롤링, 레이아웃을 유발하지 않는 애니메이션 및 메인 스레드에서 디코딩되는 이미지를 이동하기 위한 장기적인 노력. 그것은 2011년에 시작되어 현재 진행 중이다.
| 연도 | 진행 |
| 2011 | 스레드 스크롤 및 애니메이션에 대한 초기 지원. |
| 2015 | 레이어 스쿼싱. |
| 2016 | 범용 오버플로 스크롤.(Universal overflow scrolling.) |
| 2017 | Image decodes on compositor thread. |
| 2018 | Image Animations on compositor thread. |
| 2020 | Always composite fixed-position. |
| 2021 | 애니메이션, SVG 애니메이션의 백분율 변환. |
Viz
처리량을 높이고 메모리를 최적화하며 하드웨어 기능을 최적으로 사용할 수 있는 크롬을 위한 중앙 집중식 래스터 및 그리기 프로세스. 그것은 또한 웹 개발자들에게는 덜 보여지지만 사이트 격리를 차단하고 브라우저 UI 렌더링에서 렌더링 파이프라인을 분리하는 것과 같은 사용자에게 매우 보이는 다른 이점을 가지고 있다. 2016년 시작돼 2021년 완공된다.
| 연도 | 과정 |
| 2018 | OOP-R은 Android, Mac, Windows로 배송됨. |
| 2019 | OOP-D 선적. OOP-R은 캔버스를 제외한 모든 곳에 배송됨. SkiaRenderer는 리눅스로 선적되었다. |
| 2020 | SkiaRenderer는 윈도우 & 안드로이드로 선적되었다. Vulkan은 안드로이드로 선적되었다. |
| 2021 | Mac으로 배송된 SkiaRenderer(곧 ChromeOS). |
위 차트의 용어 정의:
OOP-D
디스플레이 compositor 프로세스 부족. 디스플레이 컴포지팅은OS compositor 와 같은 종류의 활동이다. 프로세스 부족은 웹 페이지의 렌더 프로세스 또는 브라우저 UI 프로세스 대신 Viz 프로세스에서 프로세스를 수행하는 것을 의미한다.
OOP-R
프로세스 종료 래스터. 래스터는 디스플레이 리스트를 픽셀로 변환하고 있다. 프로세스 부족은 웹 페이지의 렌더 프로세스 대신 Viz 프로세스에서 프로세스를 수행하는 것을 의미한다.
SkiaRenderer
Vulkan, D3D12 또는 Metal과 같은 다양한 기본 GPU API에서 실행을 지원할 수 있는 새로운 디스플레이 컴포지터 구현.
스레드 및 캔버스 렌더링 가속화
이것은 OffscreenCanvas를 가능케 한 구조들를 배치한 프로젝트다. 2015년에 시작되어 2021년에 끝난다.
| 연도 | 과정 |
| 2018 | OffscreenCanvas를 배송하십시오. |
| 2019 | ImageBitmapRenenderContext 발송. |
| 2021 | OOP-R을 선적한다. |
비디오NG
웹에서 효율적이고 신뢰할 수 있으며 고품질 비디오 재생을 제공하기 위한 장기적인 노력.
| 연도 | 과정 |
| 2014 | Mojo 기반 렌더링 프레임워크 도입. |
| 2015 | 보다 부드러운 비디오 렌더링을 위해 Project Butter 및 비디오 오버레이 발송 |
| 2016 | 통합 안드로이드 및 데스크톱 디코딩 및 렌더링 파이프라인 제공 |
| 2017 | HDR 및 컬러 보정 비디오 렌더링 발송 |
| 2018 | Mojo 기반 비디오 디코딩 파이프라인 발송. |
| 2019 | Shipped Surface-based video rendering pipeline. |
| 2021 | ChromeOS에서 4K 보호 콘텐츠 렌더링 지원 배송. |
위 차트의 용어 정의:
Mojo
크롬을 위한 차세대 IPC 서브시스템.
Surface
Viz 프로젝트 설계의 일부인 개념.
결론
웹과 크롬의 렌더링 개선 속도가 이보다 더 좋을 순 없었다. 렌더링NG의 견고한 기반 위에 우리가 구축할 수 있기 때문에 앞으로 몇 년 동안 그 속도가 계속 빨라질 것으로 기대한다.
새로운 아키텍처, 어떻게 되었는지, 어떻게 작동하는지 자세히 설명해 줄 미래의 많은 게시물에 채널을 고정하십시오.
Eirik Solheim이 Unsplash에서 찍은 장치 사진
Una Kravets.의 삽화.