Mobile Browser Internal (Blink Rendering Engine)
•
74 likes•17,279 views
This document discusses the Blink rendering engine used in Chromium and Chrome. It begins with an overview of web browser basics, including the rendering engine flow, DOM, CSS, parsing, and layout/rendering. It then covers the evolution from KHTML to WebKit to Blink. Key aspects of Blink covered include its multi-process architecture with separate browser and renderer processes, inter-process communication (IPC), multi-process resource loading, and the rendering path including software rendering, hardware acceleration using the GPU process, and threaded compositing.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Mobile Browser Internal (Blink Rendering Engine)
Similar to Mobile Browser Internal (Blink Rendering Engine) (20)
Recently uploaded
Recently uploaded (20)
Mobile Browser Internal (Blink Rendering Engine)
- 1. Mobile Browser Internals ( Understanding Blink Rendering Engine ) 이형욱 TL (hyungwook.lee@navercorp.com) 웹브라우저기술lab / NAVER LABS 2014-01
- 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
- 3. Chapter 1, Web Browser Basics 3
- 4. 1. Browser at High Level UI Data Persistence Code Coverage 10% Browser Engine Rendering Engine 90% Network I/O JavaScript Engine Graphics Stack 4
- 5. 2. Rendering Engine main flow <html> <head> <title> NHN </title> </head> <body> <div> <h1> Hello </h1> <p> World </p> </div> </body> </html> 5
- 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
- 8. 4. CSS (2/2): Visual formatting Model < Inline formatting context > < Block formatting context > < Normal Flow > < Relative Positioning > 8
- 9. 5. Loader 9
- 10. 6. Parser (1/3): Basic 10
- 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
- 12. 6. Parser (3/3): Java Script Engine Bytecode Generator Source Code Parser Bytecode Execution Syntax Tree JIT Compiler Machine Code Loader Parser DOM Java Script 12
- 13. 7. Tree Builder (1/5): DOM Tree HTML DOM Tree CSS Style Rules 13
- 14. 7. Tree Builder (2/5): Render Tree HTML DOM Tree Lookup CSS Renderer Tree Style Rules 14
- 15. 7. Tree Builder (3/5): DOM Tree & Render Tree 15
- 16. 7. Tree Builder (4/5): How DOM is Attached 16
- 17. 7. Tree Builder (5/5): Example HTML Block HEAD BODY Block TITLE DIV Block NHN H1 Hello P World Block Block Inline Inline 17
- 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) Floats 3) Absolute positioning dirty 2. Global and incremental layout 3. Dirty bit system < Incremental layout > 4. Asynchronous and Synchronous layout 18
- 19. 8. Layout (2/2): Example HTML Block (0, 0, 1024, 768) HEAD BODY Block (0, 0, 1024, 768) TITLE NHN Block DIV H1 (0, 0, 1024, 55) P Block (10, 20, 1024, 37) Hello World Inline Block (10, 80, 1024, 18) Inline 19
- 20. 9. Rendering (1/3): Overview Block (html) (0, 0, 1024, 768) Block (body) (0, 0, 1024, 768) Block (div) (0, 0, 1024, 55) Block (h1) (10, 20, 1024, 37) Inline (hello) <div> 768 Block (p) (10, 80, 1024, 18) 1024 Inline (world) 20
- 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
- 24. Chapter 2, Blink Rendering Engine 24
- 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
- 27. 3. Chromium / Blink Source Structure (Blink) 27
- 28. 4. Chromium / Blink (1/2): Structure Custom Browser Custom Content Interface Layer Chromium Test Shell Chrome Browser Browser Components ( autocomple, autofill, bookmark, devtools, download, favicon, history, omibox … ) Blink Chromium Content API Content (Multi-process-impl) Blink(WebKit) 28
- 29. 4. Chromium / Blink (2/2): Use Case Custom Content Interface Layer Browser Components (autocomplete, autofill, bookmark, devtools, download, favicon, history, omibox … ) Blink Chromium Content API Content (Multi-process-impl) Blink(WebKit) 29
- 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
- 35. 10. Rendering Path: Blink Architecture 35
- 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
- 40. 12. Browser side Compositor 40
- 45. 16. Chromium Powered WebView AOSP WebView Chromium WebView Chromium Version WebKit r.84325 Chromium 12.0.742 Chromium 30.0.1599.92 HTML5 298 428 CSS3 45% 75% DevTool X O Process single-process single-process Engine WebKit Blink Comments Android ICS부터 Update 없음. http://html5test.com http://css3test.com PC와 동일한 디버깅 환경 제공 Google에서 WebKit을 fork한 버전 45
- 49. 49