GDG Korea WebTech: 뜻밖의 워크숍 #1 "프론트엔드 개발자를 위한 크롬에서의 렌더링 성능 인자 이해하기" 관련 포스트 : http://goo.gl/kFU8rc GDG Korea WebTech: Unexpected Workshop #1 "Understanding Rendering Performance Matters in Chrome for Front-end Developers" Related post: http://goo.gl/kFU8rc

1. 뜻밖의 워크숍 #1
프론트엔드 개발자를 위한
크롬 렌더링 성능 인자 이해하기

2. Chang W. Doh
GDG WebTech Organizer
HTML5Rocks/KO Contributor/Coordinator
</hi><hi>

3.  하드웨어 가속, CPU, GPU
 GPU 렌더링 프로세스
 성능 이슈의 발생 요인
 크롬의 웹 페이지 렌더링 과정
 렌더링 성능 최적화에 대한 토론
GDG Korea WebTech - Unexpected Workshop
프론트엔드 개발자를 위한
크롬의 렌더링 성능 인자 이해
하기

4. WARNING!
간략한 설명과 이해를 위해
렌더링 하드웨어 구조 및 개념은 최신 기술과 구조가 아닌
초기 파이프라인을 기초로 설명합니다. :)

5. 하드웨어 가속
VS
같은 기능을 “하드웨어”의 지원을 통해 더 빠르게!!!!

6. 그래픽스 & 하드웨어 가속

7. VS
레스토랑의 예
http://www.bedbugbarrieorilliapestcontrol.ca/resources/RestChef2.jpg
혼자 일하는 주방장 주방장 + 보조 요리사

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

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

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

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

12. CPU + GPU

13. Software only

14. + GPU Acceleration
렌더링 작업 지
시

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

16. 성능 비교
안드로이드 3.0의 ListView의 하드웨어 가속 및 소프트웨어 렌더링의 성능 비교

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

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

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

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

21. GPU에서 일어나는 일들

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

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

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

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

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

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

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

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

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

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

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

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

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

35. 웹페이지의 렌더링

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

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

38. 컴포지트(Composite)

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

40. 이슈. 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!!

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

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

43. 크롬 DevTools: Timeline - Frame

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

45. 렌더링 성능 최적화!

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

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

48. 크롬에서 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: 레이어의 분리

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

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

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

52. 토론해볼 만한 내용들:
추측해봅시다!

53. ROCK You!