차세대 웹 콘텐츠에 대비
RenderingNG는 차세대 렌더링 아키텍처로 이전보다 성능이 훨씬 좋습니다. RenderingNG는 8년 이상에 걸쳐 빌드되었으며 많은 전용 Chromium 개발자의 공동 작업을 나타냅니다. 이를 통해 빠르고 유동적이며 안정적이며 응답성이 높은 대화형 웹 콘텐츠를 제작할 수 있는 엄청난 잠재력을 활용할 수 있습니다.
여기에서 Google이 빌드한 항목, 구축 이유, 작동 방식을 학습합니다.
북극성 골
RenderNG의 동기를 부여하는 목표는 브라우저 엔진 구현과 렌더링 API의 풍부함이 웹 UX의 제한 요소가 되어서는 안 된다는 것입니다.
따라서 기능을 불안정하게 만들거나 사이트 렌더링을 중단시키는 브라우저 버그는 걱정할 필요가 없습니다.
신비로운 성능 절벽이 없어야 합니다. 또한 기본 제공 기능이 누락되는 문제는 해결할 필요가 없습니다.
그러면 정상적으로 작동할 것입니다.
렌더링은 이 북극성 목표를 향한 큰 진전입니다. RenderNG를 도입하기 전에는 렌더링 기능을 추가하고 성능을 개선할 수 있었지만, 개발자가 이러한 기능을 안정적으로 제공하는 데 어려움을 겪었으며 성능 저하 문제가 많았습니다. 이제 이러한 문제를 체계적으로 해결할 뿐만 아니라 이전에는 실현 불가능한 것으로 여겨졌던 고급 기능의 차단을 해제하는 아키텍처가 생겼습니다. 담고 있습니다.
- 다양한 플랫폼, 기기, 운영체제에서 견고한 핵심 기능을 제공합니다.
- 예측 가능하고 안정적인 성능을 제공합니다.
- 하드웨어 기능 (코어, GPU, 화면 해상도, 화면 재생 빈도, 하위 수준 래스터 API)의 사용을 극대화합니다.
- 표시되는 콘텐츠를 표시하는 데 필요한 작업만 실행합니다.
- 일반적인 시각 디자인, 애니메이션 및 상호작용 디자인 패턴을 기본적으로 지원합니다.
- 렌더링 비용을 쉽게 관리할 수 있는 개발자 API를 제공합니다.
- 개발자 부가기능에 대한 렌더링 파이프라인 확장 지점을 제공합니다.
- HTML, CSS, 2D 캔버스, 3D 캔버스, 이미지, 동영상, 글꼴 등 모든 콘텐츠를 최적화합니다.
다른 브라우저 렌더링 엔진과 비교
Gecko와 Webkit는 또한 이 블로그 게시물에 설명된 것과 동일한 아키텍처 기능의 대부분을 구현했으며 경우에 따라 Chromium보다 먼저 이를 추가하기도 합니다.
브라우저가 더 빠르고 안정적일수록 칭찬의 대상이 되며 실질적인 영향을 미칩니다. 궁극적인 목표는 모든 브라우저의 기준을 발전시켜 개발자가 신뢰할 수 있도록 하는 것입니다.
성공의 피라미드
제 철학은 성공은 먼저 안정성을 달성한 후에 확장 가능한 성능, 그리고 최종적으로 확장성을 달성한 결과입니다.
실제 피라미드처럼 각 레벨은 상위 레벨에 대해 확실한 기초를 제공합니다.
안정성
풍부하고 복잡한 사용자 환경을 제공하기 위해서는 가장 먼저 필요한 것이 견고한 플랫폼입니다. 핵심 기능과 기초는 올바르게 작동하고 시간이 지나도 계속 작동해야 합니다. 특성이 잘 구성되고 이상한 특이한 사례 동작이나 버그가 없어야 합니다.
따라서 신뢰성은 RenderNG의 가장 중요한 단일 부분입니다. 그리고 안정성은 좋은 테스트, 고품질 피드백 루프, 측정항목, 소프트웨어 설계 패턴의 결과입니다
신뢰성이 얼마나 중요하다고 생각하는지 감을 잡을 수 있도록 지난 8년의 대부분을 이 부분만 제대로 해내는 데 할애했습니다. 먼저 시스템에 관한 심층적인 지식을 구축했습니다. 버그 보고서를 통해 취약점을 파악하여 수정하고, 포괄적인 테스트를 부트스트랩 처리하며, 사이트의 성능 요구사항과 Chromium 성능의 한계를 파악했습니다. 그런 다음 신중하게 점진적으로 설계하고 주요 설계 패턴과 데이터 구조를 배포했습니다. 그런 다음에는 렌더링의 반응형 디자인, 확장성 및 맞춤설정을 위한 진정한 차세대 프리미티브를 추가할 준비가 되었습니다.
그렇다고 해서 Chromium이 그때까지 개선된 점이 없다는 뜻은 아닙니다. 실제로는 그 반대입니다! 지난 몇 년간 각 개선사항을 단계별로 리팩터링하고 출시하면서 안정성과 성능이 꾸준히 꾸준히 향상되었습니다.
테스트 및 측정항목
지난 8년 동안 Google에서는 수만 개의 단위, 성능, 통합 테스트를 추가했습니다. 또한 Google에서는 로컬 테스트, 성능 벤치마크, 실제 사이트에서 실제 사용자와 기기를 사용한 상태에서 Chromium 렌더링이 작동하는 방식의 여러 측면을 측정하는 포괄적인 측정항목을 개발했습니다.
그러나 RenderNG (또는 다른 브라우저의 렌더링 엔진)가 아무리 뛰어나더라도 브라우저 간 버그나 동작에 차이가 많다면 웹용으로 개발하기가 쉽지 않습니다. 이 문제를 해결하기 위해 웹 플랫폼 테스트도 최대한 사용합니다. 각 테스트는 모든 브라우저에서 통과해야 하는 웹 플랫폼의 사용 패턴을 확인합니다. 또한 시간이 지남에 따라 더 많은 테스트를 통과하고 핵심 호환성을 향상하기 위해 측정항목을 면밀히 모니터링합니다.
웹 플랫폼 테스트는 공동으로 진행되며, 예를 들어 Chromium 엔지니어는 CSS 기능과 관련된 총 WPT 테스트의 약 10% 만 추가했으며 나머지는 다른 브라우저 공급업체, 독립 참여자, 사양 작성자가 추가합니다. 상호 운용 가능한 웹을 구현하려면 하나의 마을이 필요합니다.
좋은 소프트웨어 설계 패턴
코드를 이해하기 쉽고 버그 가능성을 최소화하는 방식으로 설계되었다면 고품질 소프트웨어를 안정적으로 배포하는 것이 훨씬 쉬워집니다. 이후 블로그 게시물에서 RenderingNG의 소프트웨어 설계에 대해 더 자세히 설명하겠습니다.
확장 가능한 성능
속도, 메모리, 전력 사용 차원에서 우수한 성능을 달성하는 것이 RenderNG의 두 번째로 중요한 측면입니다. Google은 기기의 안정성을 유지하면서 모든 웹사이트와의 상호작용이 원활하고 응답하기를 바랍니다.
하지만 Google은 성능만이 아니라 확장 가능한 성능, 즉 저사양 및 고급 머신과 여러 OS 플랫폼에서 안정적으로 잘 작동하는 아키텍처도 원합니다. 이를 수직 확장이라고 합니다. 즉, 하드웨어 기기가 달성할 수 있는 모든 이점을 활용한 후 축소하여 효율성을 극대화하고 필요할 때 시스템의 수요를 줄입니다.
이를 위해서는 캐싱, 성능 격리, GPU 하드웨어 가속을 최대한 활용해야 했습니다. 하나씩 순서대로 살펴보겠습니다. 구체적으로 말하자면, 각 요소가 웹페이지에서 매우 중요한 상호작용인 스크롤의 성능에 어떻게 기여하는지 생각해 봅시다.
캐싱
웹과 같은 동적인 대화형 UI 플랫폼에서 캐싱은 성능을 크게 향상시키는 가장 중요한 단일 방법입니다. 브라우저에서 가장 잘 알려진 유형의 캐싱은 HTTP 캐시이지만 렌더링에도 많은 캐시가 있습니다. 스크롤에 가장 중요한 캐시는 캐시된 GPU 텍스처와 표시 목록으로, 배터리 소모를 최소화하고 다양한 기기에서 원활하게 작동하는 동시에 매우 빠르게 스크롤할 수 있습니다.
캐싱은 배터리 수명 및 스크롤 애니메이션 프레임 속도를 개선하는 데 도움이 되지만 더 중요한 것은 기본 스레드에서 성능 격리의 차단을 해제하는 것입니다.
성능 격리
최신 데스크톱 컴퓨터에서는 작업 중인 애플리케이션이 백그라운드 애플리케이션으로 인해 느려질까봐 걱정할 필요가 없습니다. 이는 선점형 멀티태스킹이 성능 격리의 한 형태로 작용하여 독립 작업이 서로 느려지지 않도록 하기 때문입니다.
웹에서 성능 격리의 가장 좋은 예는 스크롤입니다. 느린 JavaScript가 많이 있는 웹사이트에서도 JavaScript 및 레이아웃 스레드에 종속될 필요가 없는 다른 스레드에서 실행되기 때문에 스크롤이 매우 매끄러울 수 있습니다. Google은 표시 목록뿐만 아니라 더 복잡한 상황까지 가능한 캐싱을 통해 가능한 모든 스크롤이 스레드되도록 RenderingNG에 많은 노력을 기울입니다. 예를 들어 고정 및 고정 위치 요소를 나타내는 코드, 수동적 이벤트 리스너, 고품질 텍스트 렌더링이 있습니다.
GPU 가속
GPU를 사용하면 픽셀 생성 및 화면에 그리기가 훨씬 더 빨라집니다. 대부분의 경우 모든 픽셀을 다른 모든 픽셀과 병렬로 그릴 수 있으므로 속도가 매우 빨라집니다. 렌더링의 핵심 구성요소는 GPU 래스터와 모든 곳에 그리기입니다. 이는 모든 플랫폼과 모든 기기에서 GPU를 사용하여 웹 콘텐츠의 렌더링 및 애니메이션 처리 속도를 높입니다. 이는 기기의 다른 부분보다 훨씬 성능이 뛰어난 GPU를 갖는 저사양 기기나 고급형 기기에서 특히 중요합니다.
확장성: 작업에 적합한 도구
안정성과 확장성을 확보하면 개발자가 HTML, CSS, 캔버스의 기본 제공 부분을 확장하는 데 도움이 되는 다양한 도구를 기반으로 빌드하여 어렵게 얻은 성능과 안정성을 포기하지 않는 방식으로 빌드할 준비가 되었습니다.
여기에는 반응형 디자인, 프로그레시브 렌더링, 부드러움 및 반응성, 스레드 렌더링의 고급 사용 사례를 위한 내장된 API와 JavaScript 노출 API가 포함됩니다.
Chromium이 지지하는 다음 개방형 웹 API는 RenderingNG를 통해 개발되었으며 이전에는 실행 불가능한 것으로 간주되었습니다.
이들 모두는 개방형 사양을 갖추고 개발되었으며 다른 브라우저의 엔지니어, 전문가, 웹 개발자와 같은 공개 웹 파트너와의 공동작업으로 개발되었습니다. 이어지는 블로그 게시물에서는 각각에 대해 자세히 살펴보고 RenderNG를 통해 어떻게 이런 작업이 가능한지 설명하겠습니다.
- content-Visibility: 사이트에서 쉽게 화면 밖 콘텐츠의 렌더링 작업을 피하고 현재 표시되지 않는 단일 페이지 애플리케이션 뷰에 대한 캐시 렌더링을 방지할 수 있습니다.
- OffscreenCanvas: 안정적인 우수한 성능을 위해 캔버스 렌더링(2D 캔버스 API 및 WebGL 모두)을 자체 스레드에서 실행할 수 있습니다. 이 프로젝트는 웹의 또 다른 중요한 성과이기도 합니다. JavaScript (또는 WebAssembly!)가 여러 스레드에서 단일 웹페이지 문서를 렌더링할 수 있게 하는 최초의 웹 API입니다.
- 컨테이너 쿼리: 단일 구성요소가 플러그 앤 플레이 구성요소 전체 세계를 차단 해제하여 반응적으로 자체적으로 배치될 수 있습니다 (현재 실험 단계임).
- 출처 격리: 사이트에서 iframe 간에 더 많은 성능 격리를 선택할 수 있습니다.
- 기본 스레드가 아닌 페인트 워크렛: 컴포지터 스레드에서 실행되는 코드를 사용하여 요소를 페인트하는 방식을 확장할 수 있는 방법을 개발자에게 제공합니다.
RenderNG를 통해 명시적인 웹 API 외에도 모든 사이트에 도움이 되는 다음과 같은 몇 가지 매우 중요한 '자동 기능'을 제공할 수 있었습니다.
- 사이트 격리: 더 나은 보안과 성능 격리를 위해 교차 출처 iframe을 다른 CPU 프로세스에 배치합니다.
- Vulkan, D3D12, Metal: OpenGL보다 GPU를 더 효율적으로 사용하는 하위 수준 API를 활용합니다.
- 추가로 합성된 애니메이션: SVG, 배경 색상
RenderingNG를 통해 차단 해제된 추가 출시 기능은 다음과 같습니다.
- 스크롤 연결 애니메이션.
- 숨겨져 있지만 검색 및 액세스가 가능한 DOM.
- 공유 요소 전환.
- 맞춤 레이아웃.
- 기본 스레드를 벗어난 합성, 스레딩과 합성 분리
RenderingNG를 구성하는 주요 프로젝트
다음은 RenderingNG 내의 주요 프로젝트 목록입니다.
CompositeAfterPaint
CompositeAfterPaint는 스타일, 레이아웃 및 페인트로부터 합성을 분리하여 안정성과 예측 가능한 성능을 크게 개선하고, 처리량을 늘리며, 성능 저하 없이 메모리를 적게 사용합니다.
연도 | 진행률 |
---|---|
2015 | 표시 목록 배송. |
2017 | 새 무효화를 전송합니다. |
2018년 | 선박 자산 트리 파트 1. |
2019 | 함선 사유지 트리 2부. |
2021년 | 프로젝트 배송을 완료했습니다. |
LayoutNG
안정성과 예측 가능성이 크게 개선된 모든 레이아웃 알고리즘을 처음부터 다시 작성했습니다.
LayoutNG에 대해 자세히 알아보세요.
연도 | 진행률 |
---|---|
2019 | 배송 차단 흐름 |
2020년 | Ship Flex, 수정 중. |
2021년 | 나머지는 모두 배송합니다. |
BlinkNG
Blink 렌더링 엔진을 리팩터링하고 깔끔하게 구분된 파이프라인 단계로 정리했습니다. 이를 통해 캐싱, 더 높은 안정성, 재진입 또는 지연 렌더링 기능(예: 콘텐츠 공개 상태 및 컨테이너 쿼리)이 가능합니다.
모든 곳에서 GPU 가속
GPU 가속을 사용하면 모든 픽셀이 병렬로 처리될 수 있으므로 대부분의 콘텐츠 속도가 엄청나게 향상됩니다. 또한 GPU를 사용하는 경향이 있는 저사양 기기에서 성능을 개선하는 데 효과적인 방법이기도 합니다.
연도 | 진행률 |
---|---|
2014 | 캔버스 지원 Android의 선택 콘텐츠로 전송됩니다. |
2016 | Mac에서 배송. |
2017 | GPU는 Android 페이지 조회의 60% 이상에서 사용됩니다. |
2018년 | Windows, ChromeOS, Android Go에서 출시하세요. |
2019 | 스레드된 GPU 래스터화 |
2020년 | 남은 Android 콘텐츠를 전송합니다. |
스레드 스크롤, 애니메이션, 디코딩
모든 스크롤, 레이아웃을 방해하지 않는 애니메이션, 이미지 디코딩을 기본 스레드에서 이동하려는 장기적인 노력. 진행 중입니다.
연도 | 진행률 |
---|---|
2011 | 스레드 스크롤 및 애니메이션의 초기 지원 |
2015 | 레이어 스쿼싱 |
2016 | 범용 오버플로 스크롤입니다. |
2017 | 이미지가 컴포지터 스레드에서 디코딩됨 |
2018년 | 컴포지터 스레드의 이미지 애니메이션 |
2020년 | 항상 고정 위치를 합성해야 합니다. |
2021년 | 비율 변환 애니메이션, SVG 애니메이션 |
시각화
Chromium의 중앙 집중식 래스터 및 그리기 프로세스로, 처리량을 늘리고 메모리를 최적화하며 하드웨어 기능을 최적으로 사용할 수 있습니다. 사이트 격리를 차단 해제하고 브라우저 UI 렌더링에서 렌더링 파이프라인을 분리하는 등 웹 개발자에게는 덜 눈에 띄지만 사용자에게는 잘 보이는 다른 이점이 있습니다.
연도 | 진행률 |
---|---|
2018년 | OOP-R은 Android, Mac, Windows에서 제공됩니다. |
2019 | OOP-D가 발송되었습니다. OOP-R이 모든 곳으로 배송되었습니다 (캔버스 제외). SkiaRenderer는 Linux에서 제공됩니다. |
2020년 | SkiaRenderer는 Windows 및 Android에서 제공됩니다. Vulkan은 Android에서 제공됩니다. |
2021년 | SkiaRenderer는 Mac (및 ChromeOS 출시 예정)에서 제공됩니다. |
위 차트에 사용된 용어 정의:
- OOP-D
- 처리되지 않은 디스플레이 컴포지터입니다. 디스플레이 합성은 OS 컴포지터와 동일한 종류의 활동입니다. 프로세스 밖이란 웹페이지의 렌더링 프로세스나 브라우저 UI 프로세스가 아닌 Viz 프로세스에서 이 작업을 수행하는 것을 의미합니다.
- OOP-R
- 프로세스 외부 래스터입니다. Raster는 표시 목록을 픽셀로 변환합니다. 프로세스 외란 웹페이지의 렌더링 프로세스가 아닌 Viz 프로세스에서 이 작업을 수행하는 것을 의미합니다.
- SkiaRenderer
- Vulkan, D3D12, Metal과 같은 다양한 기본 GPU API에서의 실행을 지원할 수 있는 새로운 디스플레이 컴포지터 구현입니다.
스레드 및 가속 캔버스 렌더링
이는 OffscreenCanvas를 가능케 한 프로젝트입니다.
연도 | 진행률 |
---|---|
2018년 | OffscreenCanvas로 배송. |
2019 | ImageBitmapRenderingContext 배송. |
2021년 | OOP-R을 배송합니다. |
VideoNG
VideoNG는 웹에서 효율적이고 안정적인 고품질 동영상 재생을 제공하기 위한 장기적인 노력입니다.
연도 | 진행률 |
---|---|
2014 | Mojo 기반 렌더링 프레임워크를 도입했습니다. |
2015 | 더 원활한 동영상 렌더링을 위해 Project Butter 및 동영상 오버레이가 제공되었습니다. |
2016 | 통합 Android 및 데스크톱 디코딩 및 렌더링 파이프라인이 출시되었습니다. |
2017 | HDR 및 색상 보정된 동영상 렌더링이 발송되었습니다. |
2018년 | Mojo 기반 동영상 디코딩 파이프라인이 배송되었습니다. |
2019 | Surface 기반 동영상 렌더링 파이프라인이 배송되었습니다. |
2021년 | ChromeOS에서 4K 보호 콘텐츠 렌더링 지원을 제공했습니다. |
위 차트에 사용된 용어 정의:
- 모조
- Chromium용 차세대 IPC 하위 시스템입니다.
- 표시 경로
- Viz 프로젝트 설계의 일부인 개념
일러스트레이션: Una Kravets