跳到主要內容

高性能Web動畫和渲染原理系列（4）“Compositor-Pipeline演講PPT”學習摘要

目錄

















示例代碼託管在：


博客園地址：


華為雲社區地址：





附件PPT來自開發文檔。術語里的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.【重要】軟件渲染和硬件渲染的區別


聲明：本節內容是個人理解，僅用作技術交流，不保證對！


軟件渲染和硬件渲染的區別對筆者而言一直非常抽象，只是知道基本概念。後來在（國內可能無法訪問）中《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讓它去幹活。


本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

【其他文章推薦】

※台北網頁設計公司這麼多，該如何挑選?? 網頁設計報價省錢懶人包"嚨底家"



※網頁設計公司推薦更多不同的設計風格，搶佔消費者視覺第一線



※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整



※南投搬家費用,距離,噸數怎麼算?達人教你簡易估價知識!


Orignal From: 高性能Web動畫和渲染原理系列（4）"Compositor-Pipeline演講PPT"學習摘要

留言

張貼留言

這個網誌中的熱門文章

Python 併發總結，多線程，多進程，異步IO

1 測量函數運行時間 import time def profile(func): def wrapper(*args, ** kwargs): import time start = time.time() func( *args, ** kwargs) end = time.time() print ' COST: {} ' .format(end - start) return wrapper @profile def fib(n): if n<= 2 : return 1 return fib(n-1) + fib(n-2 ) fib( 35 )   2 啟動多個線程，並等待完成   2.1 使用threading.enumerate() import threading for i in range(2 ): t = threading.Thread(target=fib, args=(35 ,)) t.start() main_thread = threading.currentThread() for t in threading.enumerate(): if t is main_thread: continue t.join()   2.2 先保存啟動的線程 threads = [] for i in range(5 ): t = Thread(target=foo, args= (i,)) threads.append(t) t.start() for t in threads: t.join()   3 使用信號量，限制同時能有幾個線程訪問臨界區 from threading import Semaphore import time sema = Semaphor...
張貼留言
閱讀完整內容

高雄十大包子名店出爐

, 圖文：吳恩文 高雄包子大賽落幕了，我只能就我個人意見， 介紹一下前十名這些包子，但是不能代表其他四位評審的意見，雖然身為評審長，我通常不會第一個表示意見，以免影響其他評審， 我主要工作是負責發問。   這次參賽的素包子很少，而且都不夠細致，又偏油，我不愛， 但是第一名的甜芝麻包－熔岩黑金包，竟然是素食得名－ 漢來蔬食巨蛋店。   這包子賣相太好，竹炭粉的黑色外皮刷上金粉，一上桌，眾人驚呼， 搶拍照，內餡是芝麻餡，混一點花生醬增稠，加入白糖芝麻油， 熔岩爆漿的程度剛剛好，我一直以為芝麻要配豬油才行、 但是選到好的黑芝麻油一樣不減香醇， 當下有二位評審就想宅配回家。   尤其特別的是，黑芝麻餡室溫易化，師傅必須要輪班躲在冷藏室內， 穿著大外套才能包，一天包不了多少，我笑說，漢來美食，集團餐廳那麼多，實力雄厚，根本是「 奧運選手報名參加村裡運動會」嘛，其他都是小包子店啊， 但是沒辦法，顯然大家都覺得它好看又好吃， 目前限定漢來蔬食高雄巨蛋店，二顆88元，可以冷凍宅配， 但是要排一陣子，因為供不應求，聽說，四月份， 台北sogo店開始會賣。   第二名的包子，左營寬來順早餐店，顯然平易近人的多，一顆肉包， 十塊錢，是所有參賽者中最便宜的，當然，個頭也小， 它的包子皮明顯和其他不同，灰灰的老麵，薄但紮實有嚼勁， 肉餡新鮮帶汁，因為打了些水，味道極其簡單，就是蔥薑，塩， 香油，薑味尤其明顯，是老眷村的味道， 而特別的是老闆娘是台灣本省人， 當年完全是依據眷村老兵的口味一步一步調整而來，沒有加什麼糖、 五香粉，胡椒粉，油蔥酥。就是蔥薑豬肉和老麵香，能得名， 應該是它的平實無華，鮮美簡單，打動人心。   這是標準的心靈美食，可以撫慰人心，得名之前，寛來順已經天天排隊，現在，恐怕要排更久了， 建議大家六七點早點上門。   第三名，「專十一」很神奇，我記得比賽最後， 大家連吃了幾家不能引起共鳴的包子，有些累，到了專十一， 就坐著等包子，其他評審一吃，就催我趕快試，我一吃， 也醒了大半。   它的包子皮厚薄適中，但是高筋麵粉高些，老麵加一點點酵母， 我心中，它的皮屬一屬二，至於餡又多又好吃，蛋黃還是切丁拌入， 不是整顆放，吃起來「美味、均衡、飽滿」。一顆二十元。   老闆是陸軍專科十一期畢業取名專十一，...
張貼留言
閱讀完整內容

韋伯連續劇終於更新 期待第一季順利完結

　　地球天文學界的跳票大王詹姆斯·韋伯空間望遠鏡 (James Webb Space Telescope，縮寫為 JWST)自 1996 年以來斷斷續續不按劇本演出的連續劇終於讓焦慮的觀眾們又等到了一次更新：五層遮陽罩測試順利完成。 裝配完成的韋伯望遠鏡與好夥伴遮陽罩同框啦。Credit: NASA 　　嚴格的測試是任何空間任務順利成功的重中之重。遮陽罩，這個韋伯望遠鏡異常重要的親密夥伴，要是無法正常運轉的話，韋伯的這一季天文界連續劇說不準就要一直拖更了。 　　詹姆斯·韋伯空間望遠鏡是歷史上造出的最先進的空間望遠鏡。它不僅是一架紅外望遠鏡，還具有特別高的靈敏度。但想要達到辣么高的靈敏度來研究系外行星和遙遠的宇宙童年，韋伯童鞋必須非常"冷靜"，體溫升高的話，靈敏度會大大折損。這個時候，遮陽罩就要大顯身手啦。 　　遮陽罩在韋伯的設計中至關重要。韋伯望遠鏡會被發射到拉格朗日 L2 點，運行軌道很高，遠離太陽、地球與月球。太陽是韋伯的主要熱量干擾的來源，其次是地球與月球。遮陽罩會有效阻斷來自這三大熱源的能量並保護韋伯維持在工作溫度正常運轉。這個工作溫度指的是零下 220 攝氏度(-370 華氏度；50 開爾文)。 上圖中我們可以看出，韋伯望遠鏡的配置大致可分為兩部分：紅色較熱的一面溫度為 85 攝氏度，藍色較冷的一面溫度達到零下 233 攝氏度。紅色的這部分中，儀器包括太陽能板、通信設備、計算機、以及轉向裝置。藍色部分的主要裝置包括鏡面、探測器、濾光片等。Credit: STSci. 　　遮陽罩的那一部分和望遠鏡的鏡面這部分可以產生非常極端的溫差。遮陽的這面溫度可以達到 110 攝氏度，足以煮熟雞蛋，而背陰處的部分溫度極低，足以凍結氧氣。 　　工程師們剛剛完成了五層遮陽罩的測試，按照韋伯在 L2 時的運行狀態安裝了遮陽罩。L2 距離地球約 160 萬公里。NASA 表示這些測試使用了航天器的自帶系統來展開遮陽罩，測試目前都已成功完成。韋伯望遠鏡遮陽罩負責人 James Cooper 介紹說這是遮陽罩"第一次在望遠鏡系統的电子設備的控制下展開。儘管這個任務非常艱巨，難度高，但測試順利完成，遮陽罩展開時的狀態非常驚艷"。 　　遮陽罩由五層 Kapton 製成。Kapton 是一種聚酰亞胺薄膜材料， 耐高溫絕...
張貼留言
閱讀完整內容