示例代碼托管在：http://www.github.com/dashnowords/blogs
博客園地址：《大史住在大前端》原創博文目錄
華為云社區地址：【你要的前端打怪升級指南】
目錄
- 摘要
- 1.合成流水線
- 2. 預定義UI層
- 3. paint是什么意思
- 4. 分層的優勢和劣勢
- 5. 視圖屬性及其處理方式
- 6. Quads
- 7. Compositor Frame
- 8. 關于光柵化以及渲染方式
- 9.【重要】軟體渲染和硬體渲染的區別
附件PPT來自chromium官方網站開發檔案，術語里的
cc指的是Chromium Compositor
一直以來都想了解瀏覽器合成層的運作機制，但是相關的中文資料大多比較關注框架和開發技術，這方面的資料實在是太少了，后來在chromium官方網站的檔案里找到了專案組成員malaykeshav在 2019年4月的一份關于瀏覽器合成流水線的演講PPT，個人感覺里面講的非常清楚了，由于沒有找到視頻，有些部分只能自行理解，本文僅對關鍵資訊做一些筆記，對此感興趣的讀者可以在文章開頭的github倉庫或附件中拿到這個PPT自行學習，
摘要
1.合成流水線
合成流水線，就是指瀏覽器處理合成層的作業流程，其基本步驟如下：
大致的流程就是說Paint環節會生成一個串列，串列里登記了頁面元素的繪制指令，接著這個串列需要經過Raster光柵化處理，并在合成幀中處理紋理，最后的Draw環節才是將這些紋理圖展示在瀏覽器內容區，
2. 預定義UI層
chromium中預定義了一些指定型別的UI層，大致分為：
- Not Drawn - 為了處理透明度或濾鏡效果、transform變形或者clip剪裁的非繪制層
- Solid color layer - 固有顏色層
- Painted texture layer - Texture紋理會在這個層執行
paint渲染和后續的rasterized光柵化任務 - Transferable resource layer - 共享資源層，可能是GPU里面的Texture紋理也可能未來會發給GPU的位圖
- Surface layer - 臨時占位層，因為自頂向下遍歷layer樹時子樹都還沒處理，需要先占位最后再填充
- Nine patch layer - 用于實作陰影的層
3. paint是什么意思
每個層layer是由若干個views組成的，所謂paint，就是每個views將自己對應圖形的繪制指令添加到層的可展示元素串列Display Item List里，這個串列會被添加到一個延遲執行的光柵化任務中，并最終生成當前層的texture紋理（可以理解為當前層的繪制結果），考慮到傳輸性能以及未來增量更新的需求，光柵化的結果會以tiles瓦片形式保存，在chrome中也可以看到頁面瓦片化拆分的結果:
4. 分層的優勢和劣勢
分層的優勢和劣勢也在此進行了說明，和之前我們主動思考的答案基本一致（暗爽一下），
5. 視圖屬性及其處理方式
views中支持的屬性包含Clip剪裁，transform變換,effect效果（如半透明或濾鏡等）,mask遮罩，通常按照后序遍歷的方式自底向上進行遍歷處理，
clip剪裁的處理方式是在父節點和子節點之間插入一個剪裁層，用來將其子樹的渲染結果剪裁到限定的范圍內，然后再向上與父級進行合并；
transform變換直接作用于父節點，處理到這個節點時其子樹都已經處理完畢，直接將整體應用變形即可；
effect效果一般直接作用于當前處理的節點，有時也會產生交叉依賴的場景；
PPT第40頁中在介紹effect效果處理時描述了兩種不同的透明度處理需求，從而引出了一個Render Surface的概念，它相當于一個臨時的層，它的子樹需要先繪制在這個層上，然后再向上與父節點進行合并，螢屏就是是根級的Render Surface，
6. Quads
Layer遍歷處理輸出的結果被稱為Quads（從意思上理解好像就是指輸出了很多個矩形方塊），每個quad都持有它被繪制到目標緩沖區所需要的資源，根據它持有的資源不同可以分為：
Solid Color-固定顏色型Texture- 紋理型Tile- 瓦片型Surface- 臨時繪圖表面型Video- 視頻幀型Render Pass-Render Surface型別的占位區，Render Surface子樹處理完后填充到關聯的Render Pass
7. Compositor Frame
合成層真正的作業要開始了，主角概念Compositor Frame(合成幀)登場，它負責將quads合并繪制在一起，膠片里59-62頁非常清楚地展示了合成的程序，最終輸出的結果就是根節點的紋理，
chromium是多行程架構，Browser Process瀏覽器行程會對選單欄等等容器部分的畫面生成合成幀來輸出，每個網頁的Render Process渲染行程會對頁面內容生成合成幀來輸出，最終的結果都被共享給GPU ProcessGPU行程進行聚合并生成最終完整的合成表面，接著在Display Compositor環節將最后的位圖展示在螢屏上，
8. 關于光柵化以及渲染方式
膠片里并沒有描述具體的光柵化的處理程序，但是layer輸出的quads看起來應該是光柵化以后的結果，推測應該是處理Display Item List中的繪圖指令時也和WebGL類似，經過頂點著色器和片元著色器的遍歷式處理機制，并在程序中自動完成像素插值，
9.【重要】軟體渲染和硬體渲染的區別
宣告：本節內容是個人理解，僅用作技術交流，不保證對！
軟體渲染和硬體渲染的區別對筆者而言一直非常抽象，只是知道基本概念，后來在【chromium開發者檔案】（國內可能無法訪問）中《Compositor Thread Architecture》這篇合成器執行緒架構的文章中找到了一些相關描述，也解開了筆者心中一直以來的疑惑，相關部分摘抄如下：
Texture Upload
One challenge with all these textures is that we rasterize them on the main thread of the renderer process, but need to actually get them into the GPU memory. This requires handing information about these textures (and their contents) to the impl thread, then to the GPU process, and once there, into the GL/D3D driver. Done naively, this causes us to copy a single texture over and over again, something we definitely don't want to do.
We have two tricks that we use right now to make this a bit faster. To understand them, an aside on “painting” versus “rasterization.”
- Painting is the word we use for telling webkit to dump a part of its RenderObject tree to a GraphicsContext. We can pass the painting routine a GraphicsContext implementation that executes the commands as it receives them, or we can pass it a recording context that simply writes down the commands as it receives them.
- Rasterization is the word we use for actually executing graphics context commands. We typically execute the rasterization commands with the CPU (software rendering) but could also execute them directly with the GPU using Ganesh.
- Upload: this is us actually taking the contents of a rasterized bitmap in main memory and sending it to the GPU as a texture.With these definitions in mind, we deal with texture upload with the following tricks:
- Per-tile painting: we pass WebKit paint a recording context that simply records the GraphicsContext operations into an SkPicture data structure. We can then rasterize several texture tiles from that one picture.
- SHM upload: instead of rasterizing into a void* from the renderer heap, we allocate a shared memory buffer and upload into that instead. The GPU process then issues its glTex operations using that shared memory, avoiding one texture copy.The holy grail of texture upload is “zero copy” upload. With such a scheme, we manage to get a raw pointer inside the renderer process’ sandbox to GPU memory, which we software-rasterize directly into. We can’t yet do this anywhere, but it is something we fantasize about.*
大概翻譯一下，方便英語水平一般的小伙伴理解，GPU處理圖片的方式是按照Texture進行貼圖的，對此不熟悉的小伙伴可以查看筆者以前發的有關Three.js相關的博文，
紋理上傳:
處理紋理的挑戰之一就是它是在渲染行程（可以理解為單個Tab網頁的行程）的主執行緒里進行的，但是最終需要將其放入GPU記憶體，這就需要將紋理資料遞交給合成器執行緒，然后再交給GPU行程（Chromium架構里有專門的GPU行程用來專門處理和GPU之間的協作任務），最后再傳遞給底層的Direct3D或OpenGL（也就是圖形學的底層技術），如果只是按照常規流程來處理，就會需要一次又一次來復制生成的紋理資料，這顯然不是我們想要的，
我們現在使用了兩個小方法來使這個流程變得快一點，它們分別作用于painting（繪制）和rasterization（光柵化）兩個階段，
- 1號知識點！！！
Painting我們用來告訴webkit為RenderObject Tree的來生成對應的GraphicsContext，通過給painting routine（繪制流程）傳遞一個GraphicsContext的具體實作來執行這些已經編排好的繪制命令，也可以傳遞一個record context（記錄背景關系）只是簡單地把繪圖命令都記錄下來，- 2號知識點！！！
Rasterization（光柵化）是指Graphics context關聯的繪圖命令實際被執行的程序，通常我們使用CPU（也就是軟體渲染的方式）來執行光柵化任務，也可以直接使用GPU來渲染（也就是硬體渲染的方式），- 上傳：指在主執行緒存盤區獲取到光柵化以后的位圖內容然后將它作為紋理上傳給GPU的程序，考慮到上述已經提及的定義，上傳程序是如下來處理的：
- 瓦片繪制：我們在webkit中使用
recording context來簡單地記錄Graphics Context的操作指令，將它存盤為SkPicture型別（直接使用軟體光柵化時生成的是SkBitmap型別），隨后可以從一張picture里面光柵化處理得到多個紋理瓦片，- 共享記憶體：在軟體渲染的方式中，光柵化的結果會被存盤在
renderer行程的堆記憶體里，現在不這樣搞了，我們重新分配了一塊共享緩沖區，然后通過它來傳遞相關物件，GPU行程隨后在獲取紋理時直接從共享記憶體中獲取就行了，這樣就避免了資料的拷貝，
總的來說，紋理上傳的程序幾乎是零拷貝的，利用這樣的結構，我們在renderer行程（也就是網頁的渲染行程）的沙箱環境內也可以獲取到指向GPU 記憶體的指標，而在軟體光柵化的程序中，是直接將位圖結果放在這里的，
- Painting: this is the process of asking Layers for their content. This is where we ask webkit to tell us what is on a layer. We might then rasterize that content into a bitmap using software, or we might do something fancier. Painting is a main thread operation.
- Drawing: this is the process of taking the layer tree and smashing it together with OpenGL onto the screen. Drawing is an impl-thread operation.
- painting:表示的程序是向Layers物件查詢層內容，也就是讓webkit告訴我們每一層上面到底有什么，接下來我們就可以使用軟體光柵化的方式將這些內容處理為位圖，也可以做一些更牛的事情，painting是一個主執行緒行為，
- drawing：是指將Layer中的內容用OpenGL繪制在螢屏上的程序，它是另一個執行緒中的操作，
概念比較多沒有基礎的讀者可能理解起來有難度，我嘗試用自己的話復述一下：
【軟體渲染】的模式下，在paint時會直接利用Graphics Context繪圖背景關系將結果繪制出來，在一個SkBitmap實體中保存為位圖資訊；【硬體渲染】的模式下，在paint時傳入一個SkPicture實體，將需要執行的繪圖命令保存在里面先不執行，然后通過共享記憶體將它傳給GPU行程，借助GPU來最終去執行繪圖命令，生成多個瓦片化的位圖紋理結果（OpenGL中頂點著色器向片元著色器傳遞資料時可以自動進行資料插值，完成光柵化的任務）， 純軟體渲染里嚴格說是沒有合成層概念的，因為最終輸出的只有一張位圖，按照順序從下往上畫，和畫到一個新層上再把新層貼到已有結果上其實是一樣的，
不管使用哪種途徑，paint動作都是得到位圖資料，而最終的draw這個動作是借助OpenGL和位圖資料最終把圖形顯示在顯示幕上，
所以【硬體渲染】就是渲染行程把要做的事情和需要的資料都寫好，然后打包遞給GPU讓它去干活，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/27959.html
標籤：HTML5
上一篇：網頁前端常用網路狀態碼串列