一、顯示
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...