一、顯示
gpu 渲染 --> 資料存幀快取區 --> 顯示控制器讀取幀快取區資料(位圖,一幀幀讀取) --> 數模轉換(大學課程已忘記...) --> 逐行掃瞄、顯示
二、螢幕撕裂
1、撕裂原因
顯示的完美路程是:每掃瞄一張圖 --> 不斷重新整理不斷掃瞄,一邊掃瞄、一邊讀取 --> 掃了最新的就正好顯示,資料實時。
但是,渲染過程中,cpu gpu 處理有一定的時間上的快取,讀取時幀快取區中仍是舊的資料 --> 那麼讀取時則讀出老的資料 --> 顯示老資料 ---> 繼續掃瞄、資料更新 --> 再讀取時資料更新完成 --> 讀取到新資料 --> 進行顯示 ==》 導致上下顯示的分別是舊資料和新資料,進而可能出現撕裂效果。下圖藍框,老舊資料顯示異常。
2、螢幕撕裂解決方案
蘋果:垂直同步vsync + 雙快取區
雙快取區:撕裂原因 - cpu/gpu 計算時,是需要時間的 --> 雙快取區 下圖流程
2個快取區依次交替,從根本上解決撕裂。
三、掉幀
雙快取區解決了撕裂(cpu/gpu 速度問題其實並未解決)。但是他引發了另乙個問題 : 掉幀
接收 vsync 訊號,但若cpu/gpu 還沒處理完新的資料 --> 幀快取區拿不到資料 --> 重複渲染顯示同一幀資料 - 掉幀
解決掉幀:三快取區(只要安卓使用了三快取區,蘋果是雙快取區) - cpu/gpu相對來說會有個閒置時間 --> 同樣是治標不治本,也是有可能出現掉幀。
撕裂的本質原因是 cpu/gpu 的計算能力跟不上幀率(60fps),而蘋果的 vsync垂直訊號和雙快取區只是讓我們察覺不到撕裂,只是偶爾會察覺掉幀,並非真正完全解決了的問題,治標不治本,類似於打補丁。但是,現實使用中,我們也很少會遇到。例:超級複雜高畫質的多圖層疊加的動畫放在 phone4 上可能會比較容易察覺到這個問題。
掉幀,也是cpu gpu計算能力,計算跟不上,出現乙個等待(重複顯示某幀)。
顯示乙個簡單的 imageview 是不會出現撕裂or掉幀的,我們在ios裝置上看到撕裂的機率極其小。
四、螢幕卡頓原因
1、cpu/gpu 流水線計算耗時長 --> 掉幀
2、垂直同步vsync + 雙快取區 強制同步,以掉幀為代價,解決螢幕撕裂
3、三快取區只能更合理的使用cpu/gpu,減少掉幀次數,並不能完全解決
五、ios下得渲染流程
核心動畫 coreanimation 渲染 (渲染流程 推薦部落格:鏈結位址)
coreanimation:渲染、構建 和 實現動畫 --render, compose, and animate visual elements.
view:1、繪製/動畫;2、布局/view管理3、互動事件的管理響應等
layer:渲染/動畫。只負責顯示 -- 位圖
opengl 螢幕座標
建立opengl模型過程 opengl座標變換很有特點,為了簡單描述先定義2個座標系 1 世界座標系 無論如何變換,世界座標系都不動,以螢幕中心為原點 0,0,0 你面對螢幕,你的右邊是x正軸,上面是y正軸,螢幕指向你的為z正軸。2 當前繪圖座標系 即區域性座標系 當前繪圖座標系是繪製物體時的座標系...
OpenGL 螢幕座標向OpenGL座標轉換
螢幕座標向opengl座標轉換 很多人用opengl繪圖會遇到乙個問題即螢幕座標向opengl座標轉換,在網上流傳著如下類似的 glint viewport 4 gldouble modelview 16 gldouble projection 16 glfloat winx,winy,winz g...
螢幕座標向OpenGL座標轉換
很多人用opengl繪圖會遇到乙個問題即螢幕座標向opengl座標轉換,在網上流傳著如下類似的 glint viewport 4 gldouble modelview 16 gldouble projection 16 glfloat winx,winy,winz gldouble posx,pos...