프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기

GDG DevFair 2014
프론트엔드 개발자를 위한
크롬 성능 인자 이해하기

Agenda
Rendering Performance
ServiceWorker

H/W Acceleration
for Graphics

S/W 렌더링과 H/W Acc. 렌더링

소프트웨어 렌더링의 실행 구조

소프트웨어 렌더링 성능
응용 프로그램의 실행 성능 =
주요 기능의 수행 시간 + 그래픽스 출력 시간

대량의 연산이 필요한 렌더링의 경우

+ GPU Acceleration
렌더링 작업 지시

http://www.bedbugbarrieorilliapestcontrol.ca/resources/RestChef2.jpg

CPU와 GPU 사이에
존재하는 이슈들

이슈 1. 서로 다른 메모리 공간
“CPU와 GPU는 전혀 다른 메모리 공간을 사용”
CPU
Main Memory
GPU
Video Memory
BUS
무엇을 그려야 하는지 알려주세요!

이슈 2. 메모리는 한계가 있다.
“처리할 모든 데이터는 메모리에, 하지만 한계가...”
코드 이미지 데이터
또 다른 코드 또 다른 데이터
Memory
새로운
데이터
?????
“더 이상 저장할 수 없으면 어떻게???”

이슈 3. 데이터는 자주 변경된다.
“CPU의 데이터 변경 시 GPU 메모리도 변경 필요”
CPU가 변경한 이미지(메인 메모리) GPU가 알고 있는 이미지(VRAM)
디스플레이?
“모르는 걸 어떻게 그려요?”

간단한 3D 그래픽스 개념 &
GPU의 렌더링 동작

Vertex & Polygon
“공간 좌표(Vertex)가 모여 도형(Polygon)을...”

Texture & Texture Mapping
“이미지(Texture)를 도형에 씌워 그리기(Mapping)”

변환(Transform)
“회전/확대/축소/기울임/...”

20년 전의 렌더링 파이프라인
우리가 말하는 비디
오 메모리
버텍스가 모여서
폴리곤에
텍스쳐를 입혀서
디스플레이 이미지로

하드웨어 가속 렌더링의
성능 최적화를 위한 첫걸음:
GPU가 잘하는 것과 못하는 것의 이해

GPU가 잘하는 것
“GPU는 수신된 데이터로 무언가를 그리는데 적합”
1. 텍스쳐를 가지고 이미지를 빠르게 출력 가능
2. 이미 가진 텍스쳐는 다시 받지 않고 재활용
3. 회전, 확대, 축소, 기울임, 반투명 처리 등
4. 위 기능들의 동시 처리하는 것도 매우 최적화

그렇다면
GPU의 동작을 방해하는 일들은?

비디오 메모리로의 데이터 전송 속도
FACT> “비디오 메모리로의 데이터 전송은 느림”
CPU
Main Memory
GPU
Video Memory
BUS

이슈: 비디오 메모리로의 전송 속도
“데이터 전송 시간 = 데이터의 크기 / BUS 속도”
● 일반적으로 예상되는 데이터 크기:
o GPU 명령 < 버텍스 < 텍스쳐 이미지

더 큰 이슈: CPU 처리 시간
FACT> “GPU의 데이터는 CPU에서 생성 후 전송”
CPU
데이터
GPU
2 VRAM
1
3
렌더링
예> 코드에 의해
텍스쳐로 사용될
이미지를 생성
즉, 렌더링의 관점에서 GPU에서 사용될 데이터를 새로 만들어서 이를 전송하는 과정은 하나의 과정!

중간 점검: 렌더링 성능의 주요 인자
1. GPU는 회전/확대/축소/기울임/반투명 처리 등에 최적화
a. 이 범주의 기능으로 렌더링이 처리될 수 있도록
2. GPU에서 사용할 데이터를 준비하는 것은 CPU의 몫
a. CPU가 새로운 데이터를 만드는 작업은 최소화
3. CPU가 준비한 데이터는 비디오 메모리에 전송 필요
a. 데이터의 전송을 최소화할 수 있도록...

크롬의 하드웨어 가속
렌더링 메커니즘

크롬의 렌더링
1. 웹 페이지는 파싱을 통해 DOM 트리로 해석되어 메모리에 적재
2. DOM 트리를 렌더링 트리로 생성 후 각 노드들을 개별적인 이미지로 생성
3. 트리 구조 및 스타일에 따라 이미지를 배치 및 합성하여 출력

레이어 모델
레이어(Layer)?
웹페이지를 렌더링하기 위해 필요한 이미지 단위의 요소
● 각 레이어는 최종적으로 표현될 이미지를 생성하는 단위
● 생성된 이미지는 텍스쳐로서 GPU에 업로드
● 레이어들을 배치/합성하여 최종적인 웹페이지 표현
NOTE!
● 레이어의 이미지는 CPU에서 생성!
o 즉, 레이어에서 생성되는 이미지는 CPU 시간 소모!
4개의 레이어로 이루어진 웹 페이지의 예

이슈: Reflow
● Reflow = Layout = Layouting
o DOM 노드가 가지는 레이아웃 정보(Geometry)가 변경되
면 레이아웃은 재배치를 위한 계산이 필요
Header
DIV
Footer
Header
DIV
Footer

이슈. Reflow로 발생할 수 있는 일
Node Node
Node
Node
Node#A
Node
Node#A
{
border: 30px;
}
Invalidate Invalidate
Invalidate
1. 레이아웃의 변경이 트리를 따라 전파 (CPU)
2. 많은 경우 레이어 이미지의 갱신 필요 (CPU)
3. 레이어 이미지가 변경되면 VRAM의 텍스쳐 갱신 필요 (RAM to VRAM Bandwidth!!!)
INVALIDATE!!

이슈: Repaint
● Repaint = Redraw
o 레이아웃 내 컨텐츠가 변경 시 텍스쳐를 새로 생성 필요
CPU
데이터
GPU
2 VRAM
1
3
렌더링
이 그림 기억하십니까?

이슈: Reflow/Repaint 발생 요인
● DOM 노드의 동적인 추가/삭제/업데이트
● DOM 노드의 감춤/표시
o display: none
o visibility: hidden
● DOM 노드의 이동, 애니메이션
● 스타일시트의 추가 혹은 스타일 속성의 변경
o 미디어 쿼리 역시
● 브라우저 사이즈 변경
● 폰트 변경
● 스크롤
● …

크롬 DevTools: Timeline - Frame

정리: 크롬에서의 전반적인 렌더링 흐름
1. DOM으로부터 노드들을 개별적으로 혹은 그룹 지어 레이어 단위들로 분리
2. 레이아웃을 계산하고 각 레이어들이 그려져야 할 영역의 크기 위치 등을 계산
a. 위치/크기 정보 등을 계산하기 위한 CPU의 계산 오버헤드가 발생
3. 레이어들 각각은 렌더링을 위해 비트맵으로 출력
a. CPU에서 레이어 이미지를 생성하는 오버헤드가 발생
4. 생성된 비트맵을 GPU에 텍스쳐로 업로드
a. GPU의 비디오 메모리로 전송하는 오버헤드는 발생
5. 계산된 레이아웃으로 레이어의 텍스쳐 이미지들을 최종 스크린 이미지로 합성

최적화에 대한 그래픽 모듈의 구현 관점
● 네이티브 어플리케이션 관점:
o 최대한 가벼운 렌더링 프로세스의 구성이 목적
> 3D 혹은 2D 게임 개발의 예
“이번 게임은 꽤 그래픽 출력이 많기 때문에 CPU와 GPU 사이의 병목 구간을 최소
화할 수 있도록 텍스쳐의 생성/업로드를 병목 구간 전에 미리 처리하고, 텍스쳐 캐싱
정책을 블라블라한 모델에 따라 관리하도록 모듈을 !@#!@$ 하게 작성합니다.
또한 우리 게임에서 특별하게 발생할 몇몇 상황에도 이러한 렌더링 모듈에 대한 커스
텀 구현으로 이를 회피할 방법을 찾을 수 있을 것입니다.” - A개발팀장의 커피톡

웹 페이지에서의 렌더링 최적화는...
● 빠른 렌더링 패스를 구현하는 것이 아니다!!!
o 렌더링 패스는 철저하게 브라우저의 영역
o 웹 렌더링 성능 최적화는 만드는 것이 아니라 병목 구간의 발
생 요인을 피해가는 것!
● 피해야 할 성능의 위험 인자
o CPU에서 텍스쳐 이미지를 생성하는 요인들
o 가급적이면 레이아웃 변경의 요인도!!

가장 간단한 Hack: 레이어의 분리
크롬에서 DOM 노드가 레이어로 분리되는 조건들
1. 3D 혹은 Perspective를 표현하는 CSS transform 속성을 가진 경우
2. 하드웨어 가속 디코딩을 사용하는 <video> 엘리먼트
3. 3D 컨텍스트 혹은 하드웨어 가속 2D 컨텍스트를 가지는 <canvas> 엘리먼트
4. (플래시와 같은) 플러그인 영역
5. 투명도(opacity) 속성 혹은 transform 애니메이션의 사용
6. 가속 가능한 CSS 필터를 가진 경우
7. Compositing Layer를 하위 노드로 가진 경우
8. 낮은 z-index를 가진 형제 노드가 Compositing Layer를 가진 경우

가장 간단한 Hack: 레이어의 분리
분리 조건 요약: 해당 DOM 노드가 주변 노드와는 별도로 렌더링되어야 빠른 경우
예1> 투명도(Opacity): 겹쳐진 다른 이미지와 픽셀 단위의 블렌딩(Blending)되는 경우.
하지만 애니메이션에서만 성능 이슈가 발생하므로 애니메이션일 경우만 분리
예2> 매번 표시되는 프레임이 변경되는 <video> 엘리먼트.
개발자의 Hack! translateZ(0);
● translateZ(0);는 노드의 Z축 값으로 0을 주는 무의미한 코드
● 그러나 레이어 분리 조건의 첫번째 항목에 해당

강제적인 레이어 분리가 만능은 아니다!
● 왜?
o 레이어 분리는 필연적으로 텍스쳐 이미지 분리를 의미
§ 추가적인 메모리 소모
o 메모리는 유한하다!
§ 메모리 공간 부족 시 기존 데이터 릴리즈 후 새로운 데이터의 업로드
● 최악의 경우가 반복되면...
§ 레이어 분리를 통한 성능 이점을 송수신 오버헤드로 상쇄
● 따라서, 레이어 분리는 최소화 필요!!!

하드웨어 가속으로 얻는 성능은
절대로 공짜가 아님! :)
모든 것에 가능성을 두고 확인!

References
1. 브라우저는 어떻게 동작하는가.
2. 크롬의 렌더링 가속: 레이어 모델
3. GPU Accelarated Compositing in Chrome
4. Scrolling Performance
5. Jank Busting for Better Rendering Performance
6. CSS 페인트 타임과 페이지 렌더 가중치
7. 불필요한 페인팅 회피하기
8. 불필요한 페인팅 회피하기: Animated GIF 버전
9. 고성능 애니메이션
10. Rendering: repaint, reflow/relayout, restyle
11. How (not) to trigger a layout in WebKit

http://goo.gl/x0E3g3
Wicked Fast
- Performance investments
@Chrome Dev Summit 2014

Offline!! App. Cache!!
App. Cache!!
Offline!!
Image: ‘Mission Impossible 4’ Movie

We forgot something!
But…what?

Mission Impossible:
● Truely controlling offline resources
o Application Cache? OMG!
o Everything managed by your webbrowser!
● Plus, background processing
o Remote Push Notification, Alarm, Background-update
of resources, ...
o Everything run on your webpage!

‘ServiceWorker’ solves...
● Truely controlling offline/network stack
o Programmable cache control
o Custom response
● Plus, background processing
o Remote Push Notification
o Task Scheduler(e.g. Local Notification)
o BackgroundSync
o ...

Overview: Service Worker
● Event-driven scripts
o that run independently of web pages
● ServiceWorker has
o Access to domain-wide events such as network
fetches
o scriptable caches
§ The ability to respond to network requests
from certain web pages via script
§ A way for applications to "go offline"

Sufficient response
http://www.slideshare.net/jungkees/service-workersa

Insufficient response

Bring your own cache

Fallback to network

What can we do with ServiceWoker?
● Eliminating loading time
o Developer knows what is most important resource in
our webpages.
§ We can control ‘request/response flow’ and
‘cache’ with ServiceWorker.
§ and Front-end developers just write their code
without other libraries to control data-flow.
o Your page will be loaded in an instant!!!
● Other features come and see us soon. :)

Demo from Google I/O 2014: Topeka

// ServiceWorker is ‘Installed’!!!
this.addEventListener("install", function(e) {
e.waitUntil( caches.create("core") // Creating Cache ‘core’!
.then(function(core) {
var resourceUrls = [
"",
"?offline",
"components/core-ajax/core-ajax.html",
// ...
];
return Promise.all(resourceUrls.map(function(relativeUrl) {
// Add resource to cache ‘core’
return core.add(baseUrl + relativeUrl);
}));
}));
});

this.addEventListener("fetch", function(e) {
var request = e.request;
if (this.scope.indexOf(request.origin) == -1) { return; }
// Basic read-through caching.
e.respondWith(
caches.match(request, "core").then(
function(response) { return response; },
function() {
// we didn't have it in the cache, so add it to the cache and return it
return caches.get("core").then(
function(core) { log("runtime caching:", request.url);
// FIXME(slighltyoff): add should take/return an array
return core.add(request).then(
function(response) {
return response;
});
// ...

References
1. ServiceWorker first draft published
2. Specification
3. Explainer
4. Implemetation Considerations
5. Service Workers: Bring your own magic
6. Topeka Demo @Google I/O 2014
7. webapplication.kr

프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à 프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기

Similaire à 프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기 (20)

Plus de Chang W. Doh

Plus de Chang W. Doh (20)

Dernier

Dernier (8)

프론트엔드 개발자를 위한 크롬 렌더링 성능인자 이해하기