2. 0. Contents
1. Chapter 1: Web Browser Basics
①
②
③
④
⑤
⑥
2.
Browser at High Level
Rendering Engine main flow
DOM (Document Object Model)
CSS (Cascading Style Sheets)
Loader, Parser, Tree Builder
Layout, Rendering
Chapter 2: Blink Rendering Engine
①
②
③
④
⑤
⑥
⑦
⑧
⑨
⑩
⑪
⑫
KHTML -> WebKit Vs Blink
Chrome Vs Chromium
Chromium / Blink Source Structure
Chromium / Blink Structure, Use Case
Why multi-process architecture
Blink Multi Process Architecture
Multi-process resource loading
Rendering Path
GPU Process
Threaded Compositor
Threaded Rasterization
Chromium powered WebView
2
6. 3. DOM (Document Object Model)
+
DOM: Document Object Model
- Document = HTML, well-formed XML
- Object Model = Data + Method
Standard way for accessing and manipulating documents.
6
7. 4. CSS (1/2): Box model
The way the box is layed out is determined by
Box type: inline, block
Box dimensions: width, height
Positioning scheme: static, absolute, fixed, relative
External information: image size / view port size
Default style sheet for HTML 4
html, address,
blockquote,
body, dd, div,
dl, dt, fieldset, form,
frame, frameset,
h1, h2, h3, h4,
h5, h6, noframes,
ol, p, ul, center,
dir, hr, menu, pre { display: block;}
* Default display property: inline
7
11. 6. Parser (2/3): Example
HTML
<html>
<head>
<title> NHN </title>
</head>
<body>
<div>
<h1> Hello </h1>
<p> World </p>
</div>
</body>
</html>
HEAD
BODY
TITLE
DIV
NHN
H1
P
Hello
World
11
21. 9. Rendering (2/3): Double Buffering
< Single Backing Store >
< Tiled Backing Store >
21
22. 9. Rendering (3/3): GPU Acceleration
1. 각 Layer 별 bitmap을 생성 (Render Layer traversing)
2. Textures upload into Video memory
3. Compositor에서 Layer 순서에 맞게 Texture를 drawing하여 화면에 Update
22
23. 10. Summary of browser main flows.
Loading
HTML
Parsing
Layouting
Layout
DOM
Tree
HTML
Parser
Platform drawing callback.
Render
Tree
attach()
CSS Style
Sheet
Painting
Display
Painting
Style
Rule
CSS
Parser
DOM Tree
Render Tree
DOM
Node
Render
Layer
Render
Object
DOM
Node
Render
Object
DOM
Node
Render
Layer
Render
Object
DOM
Node
Render
Object
DOM
Node
DOM
Node
Render
Object
Render
Layer
Render
Object
Render
Layer
23
25. 1. KHTML -> WebKit Vs Blink
KHTML, KJS (1999.05 ~)
WebKit (2001 ~)
Open Source in 2005
Apple Forks KHTML, KJS in 2001
Google Forks WebKit in 2013
Blink (2013.04 ~)
25
26. 2. Chrome Vs Chromium
Google Chrome
Chromium
Logo
Colorful
Blue
Crash reporting
Yes, if you turn it on
None
User metrics
Yes, if you turn it on
No
Video and audio tags
AAC, MP3, Vorbis and Theora
Vorbis and Theora by default
Adobe Flash
custom (non-free) plugin
included in release
supports NPAPI plugins,
including the one from Adobe
PDF support
custom (non-free) plugin
included in release
downloads and displays with
system PDF viewer
Code
Tested by Chrome developers
May be modified by
distributions
Sandbox
Always on
Depending on the distribution
Quality Assurance
New releases are tested before
sending to users
Depending on the distribution
26
30. 5. Why multi-process architecture?
기존 브라우저의 문제점
• 현재(크롬 제작 당시)의 브라우저는 과거의 OS와 비슷한 구조
• 과거의 OS는 단일 사용자, 협조적 멀티 태스킹 시스템
• 이와 같은 시스템에서, 어떤 어플리케이션의 문제는 OS 전체의 안정성에 영향을 미침
• 단일 프로세스 모델의 브라우저에서는 한 페이지의 문제가 브라우저 전체에 문제를 일으킴
문제해결을 위한 접근
• 절대적으로 안정적인 렌더링 엔진을 만드는 것은 거의 불가능함
• 최근의 OS는 각 어플리케이션을 고립시킴으로써 특정 어플리케이션의 문제가 시스템 전체의 안정
성에 영향을 미치지 않도록 하며, 사용자 각자의 데이터를 보호하고 있음
30
31. 6. Blink Multi Process Architecture
Browser Process와
Renderer Process의 연결 구조
Renderer Process의 각 View
역시 Browser Process에
연결 고리를 가짐
각 프로세스별로
입출력을 위한 스레드가
별도로 존재
Renderer Process에
WebKit 렌더링 엔진 존재
31
32. 7. Blink IPC (Inter-process communication)
Browser Process IPC
• Browser Process 내에서 별도의 I/O Thread가 IPC를 담당하게 됨
• Main Thread와의 메시지 교환은 IPC::ChannelProxy를 통해 이루어짐
• I/O Thread를 사용하는 이유는 성능상 영향을 많이 주는 네트워크 처리 요구 메시지 등을 전담하
여 처리함으로써 사용자 인터페이스에 영향을 주지 않도록 하기 위함
• I/O Thread 내부에서 처리할 메시지를 걸러내기 위해 ChannelProxy::MessageFilter 사용
Renderer Process IPC
• Renderer Process 내에서 별도의 I/O Thread가 IPC를 담당하게 됨
• 웹 페이지 렌더링을 비롯한 기타 작업은 Render Thread (Main Thread)에서 이루어짐
• 스레드를 분리함으로써 브라우저로의 동기적인 메시지 송수신이 가능
32
33. 8. Blink Multi Process Architecture in detail
Browser Process
IPC
RenderWidgetHost
RenderViewHost
Manager
WebContents
SiteInstance
RenderViewHost
RenderProcessHost
RenderWidgetHost
RenderViewHost
2
1
RenderViewHost
Manager
WebContents
RenderMainThread
(Single Process Mode)
Process Launcher
Thread
SiteInstance
RenderProcessHost
RenderWidgetHost
RenderViewHost
Cache Thread
File Thread
Main Thread
DB Thread
UI Thread
RenderWidget
WebKit
RenderWidget
I/O
Thread
RenderView
6
Main Thread
4
5
3
Renderer Process
Renderer Process
Main Thread
IO Thread
RenderWidget
RenderView
RenderView
WebKit
WebKit
I/O
Thread
33
34. 9. Multi Process Resource Loading
• Renderer Process는 독립적인 I/O Thread를 통해 Browser Process에 접근.
• Browser Process의 I/O Thread에서 ResourceMessageFilter로 요청을 Intercept.
• Network Stack이 Browser Process에 Embedded된 구조의 특징
Socket pool and connection limits, Socket reuse, Socket late-binding, Consistent
session state, Global resource and network optimizations, Predictive optimizations
34
36. 10. Rendering Path: Software Rendering Path
1. Renderer Process에서 skia를 이용하여 bitmap을 생성 (필요 시 compositing)
2. Shared Memory를 이용하여 Browser Process에 전달하여 화면에 Update.
36
37. 10. Rendering Path: Hardware Rendering Path
1. 각 Layer 별 bitmap을 생성 (Render Layer traversing)
2. Textures upload into Video memory
3. Compositor에서 Layer 순서에 맞게 Texture를 drawing하여 화면에 Update
37
38. 11. GPU Process: Overview
•
GPU Process의 구조적 특징: Security, Robustness, Uniformity, Parallelism
•
Client(Render Process): GL Command를 생성, Ring Buffer에 Insert
-> 일반적인 페이지의 경우 Texture Upload용으로 사용, HTML5 Canvas / WebGL은 직접 GL Command를 사용
•
Server(GPU Process): Command를 fetch, execution.
•
GL command는 GL ES 2.0 API와 거의 유사한 Async command
38
39. 11. GPU Process: Rendering with the compositor
3. GL Command로 Texture Quad요청
2. GL Command로 Textures Upload 요청
1. Compositor에서 bitmap을 생성
39