mobile browser internal (blink rendering engine)
DESCRIPTION
1. How browsers work. 2. Understanding Chromium/Blink Engine.TRANSCRIPT
Mobile Browser Internals( Understanding Blink Rendering Engine )
이형욱 TL ([email protected])
웹브라우저기술lab / NAVER LABS
2014-01
2
0. Contents
1. Chapter 1: Web Browser Basics① Browser at High Level② Rendering Engine main flow③ DOM (Document Object Model)④ CSS (Cascading Style Sheets)⑤ Loader, Parser, Tree Builder⑥ Layout, Rendering
2. 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
3
Chapter 1, Web Browser Basics
4
1. Browser at High Level
Co
de C
ove
rag
e
10%
90%
UI
Browser Engine
Rendering Engine
Network I/O
JavaScript Engine
Graphics Stack
Data
Persiste
nce
5
2. Rendering Engine main flow
<html><head>
<title> NHN </title></head><body>
<div><h1> Hello </h1><p> World </p>
</div></body>
</html>
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.
+
7
4. CSS (1/2): Box model
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
Default style sheet for HTML 4
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
8
4. CSS (2/2): Visual formatting Model
< Relative Positioning >< Normal Flow >
< Block formatting context >
< Inline formatting context >
9
5. Loader
10
6. Parser (1/3): Basic
11
6. Parser (2/3): Example
HEAD
TITLE
NHN
BODY
DIV
H1 P
HTML
Hello World
<html><head>
<title> NHN </title></head><body>
<div><h1> Hello </h1><p> World </p>
</div></body>
</html>
12
6. Parser (3/3): Java Script Engine
Source Code Parser Syntax Tree
BytecodeGenerator
Bytecode
JIT Compiler Machine Code
Execution
Loader
Parser
DOM
Java Script
13
7. Tree Builder (1/5): DOM Tree
HTML
CSS
DOMTree
StyleRules
14
7. Tree Builder (2/5): Render Tree
HTML
CSS
DOMTree
StyleRules
RendererTreeLookup
15
7. Tree Builder (3/5): DOM Tree & Render Tree
16
7. Tree Builder (4/5): How DOM is Attached
17
HEAD
TITLE
NHN
BODY
DIV
H1 P
HTML
Hello World
Block
Block
Block
Block Block
Inline Inline
7. Tree Builder (5/5): Example
18
8. Layout (1/2): Algorithm Overview
1. CSS 2.1 Visual formatting Model.
1) Normal Flow① Block formatting contexts② Inline formatting contexts③ Relative positioning
2) Floats3) Absolute positioning
2. Global and incremental layout
3. Dirty bit system
4. Asynchronous and Synchronous layout
dirty
< Incremental layout >
19
8. Layout (2/2): Example
HEAD
TITLE
NHN
BODY
DIV
H1 P
HTML
Hello World
Block
Block
Block
Block Block
Inline Inline
(0, 0, 1024, 768)
(0, 0, 1024, 768)
(0, 0, 1024, 55)
(10, 20, 1024, 37) (10, 80, 1024, 18)
20
9. Rendering (1/3): Overview
Block (html)
Block (body)
Block (div)
Block (h1) Block (p)
Inline (hello) Inline (world)
(0, 0, 1024, 768)
(0, 0, 1024, 768)
(0, 0, 1024, 55)
(10, 20, 1024, 37) (10, 80, 1024, 18) 1024
768<div>
21
9. Rendering (2/3): Double Buffering
< Tiled Backing Store >< Single Backing Store >
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
23
10. Summary of browser main flows.
DOM Node
DOM Node
DOM Node
DOM Node
DOM Node
DOM Node
Render Object
Render Object
Render Object
Render Object
Render Object
Render Object
Render Layer
Render Layer
Render Layer
Render Layer
HTML
CSS Style Sheet
HTML Parser
CSS Parser
DOMTree
StyleRule
attach()Render
Tree
Layout
Painting Display
Parsing Layouting Painting
DOM Tree Render Tree
Loading
Platform drawing callback.
24
Chapter 2, Blink Rendering Engine
25
1. KHTML -> WebKit Vs Blink
KHTML, KJS (1999.05 ~)
Blink (2013.04 ~)
WebKit (2001 ~)Open Source in 2005
Apple Forks KHTML, KJS in 2001
Google Forks WebKit in 2013
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 Flashcustom (non-free) plugin included in release
supports NPAPI plugins, including the one from Adobe
PDF supportcustom (non-free) plugin included in release
downloads and displays with system PDF viewer
Code Tested by Chrome developersMay be modified by distributions
Sandbox Always on Depending on the distribution
Quality AssuranceNew releases are tested before sending to users
Depending on the distribution
27
3. Chromium / Blink Source Structure
(Blink)
28
4. Chromium / Blink (1/2): Structure
Blink(WebKit)
Content (Multi-process-impl)
Content API
Custom Browser
ChromiumTest Shell
ChromeBrowser
BrowserComponents
( autocomple, autofill, bookmark, devtools,download, favicon, history, omibox … )
Blin
k
Ch
rom
ium
Custom Content Interface Layer
29
4. Chromium / Blink (2/2): Use Case
Blink(WebKit)
Content (Multi-process-impl)
Content API
BrowserComponents
(autocomplete, autofill, bookmark, devtools,download, favicon, history, omibox … )
Blin
k
Ch
rom
ium
Custom Content Interface Layer
30
5. Why multi-process architecture?
기존 브라우저의 문제점
• 현재(크롬 제작 당시)의 브라우저는 과거의 OS와 비슷한 구조
• 과거의 OS는 단일 사용자, 협조적 멀티 태스킹 시스템
• 이와 같은 시스템에서, 어떤 어플리케이션의 문제는 OS 전체의 안정성에 영향을 미침
• 단일 프로세스 모델의 브라우저에서는 한 페이지의 문제가 브라우저 전체에 문제를 일으킴
문제해결을 위한 접근
• 절대적으로 안정적인 렌더링 엔진을 만드는 것은 거의 불가능함
• 최근의 OS는 각 어플리케이션을 고립시킴으로써 특정 어플리케이션의 문제가 시스템 전체의 안정
성에 영향을 미치지 않도록 하며, 사용자 각자의 데이터를 보호하고 있음
31
6. Blink Multi Process Architecture
각프로세스별로입출력을 위한 스레드가별도로 존재
Browser Process와Renderer Process의연결 구조
Renderer Process의각 View역시 Browser Process에연결 고리를 가짐
Renderer Process에WebKit 렌더링 엔진 존재
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)에서 이루어짐
• 스레드를 분리함으로써 브라우저로의 동기적인 메시지 송수신이 가능
33
8. Blink Multi Process Architecture in detail
Renderer Process
Process LauncherThread
Cache Thread File Thread DB Thread UI Thread IO Thread
I/O Thread
Browser Process
Main Thread
Renderer Process
IPC
RenderView
RenderWidget
WebKit
RenderView
RenderWidget RenderWidget
WebKit WebKit
RenderView
WebContentsRenderViewHost
ManagerRenderViewHost
RenderWidgetHost
RenderViewHost
RenderWidgetHost
RenderViewHost
RenderWidgetHost
SiteInstance RenderProcessHost
SiteInstance RenderProcessHost
I/O Thread
Main ThreadMain Thread
WebContentsRenderViewHost
Manager
RenderMainThread(Single Process Mode)
1
2
3
45
6
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
35
10. Rendering Path: Blink Architecture
36
10. Rendering Path: Software Rendering Path
1. Renderer Process에서 skia를 이용하여 bitmap을 생성 (필요 시 compositing)
2. Shared Memory를 이용하여 Browser Process에 전달하여 화면에 Update.
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
38
• 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
11. GPU Process: Overview
39
11. GPU Process: Rendering with the compositor
1. Compositor에서 bitmap을생성
2. GL Command로 Textures Upload 요청
3. GL Command로 Texture Quad요청
40
12. Browser side Compositor
41
13. Rendering: Ideal
42
13. Rendering: Real
43
14. Threaded Compositor
44
15. Threaded Rasterization
45
AOSP WebView Chromium WebView Comments
Chromium Version
WebKit r.84325Chromium 12.0.742
Chromium30.0.1599.92
Android ICS부터 Update 없음.
HTML5 298 428 http://html5test.com
CSS3 45% 75% http://css3test.com
DevTool X O PC와 동일한 디버깅 환경 제공
Process single-process single-process
Engine WebKit Blink Google에서 WebKit을 fork한 버전
16. Chromium Powered WebView
46
Appendix #1: Vocabulary
47
Appendix #2: Chrome://tracing
48
Appendix #3: References
1. http://www.w3.org/TR/CSS2/
2. http://www.w3.org/TR/DOM-Level-2-Core/core.html
3. http://www.html5rocks.com/en/tutorials/internals/howbrowserswork/
4. http://deview.kr/2013/detail.nhn?topicSeq=5
5. http://www.slideshare.net/joone/hardware-acceleration-in-webkit
6. http://dev.chromium.org/developers/design-documents/multi-process-architecture
7. http://dev.chromium.org/developers/design-documents/displaying-a-web-page-in-
chrome
8. http://dev.chromium.org/developers/design-documents/inter-process-communication
9. http://dev.chromium.org/developers/design-documents/multi-process-resource-
loading
10. http://dev.chromium.org/developers/design-documents/gpu-accelerated-
compositing-in-chrome
11. http://dev.chromium.org/developers/design-documents/compositor-thread-
architecture
12. http://dev.chromium.org/developers/design-documents/impl-side-painting
49