最近開始在啃game programming gem 8.裡面有一些不錯的文章，及時咀嚼及時反思 記錄於此。
一直以為字型渲染是件簡單的事 ，因為電腦上這麼多字型顯示麼，但是今天看了這文章才知道3d技術裡的字型渲染是兩回事。平時win裡面看到的文字這些基本都是通過gdi在cpu上運算繪製（或者也加入了顯示卡繪製）的，不過在3d遊戲裡面看到的字型包括gui等則不是這個流程的，它們都跟其他圖形的渲染一樣，都是一些多邊形，經過渲染管線在顯示卡上繪製的，跟多邊形的渲染時一樣的，甚至有時是乙個比較耗的過程。
通常字型的渲染有兩種方式：
1 是把turetype字頭的每個字元影象（英文稱glyph）編碼為三角形集合，然後就想渲染三角形一樣在螢幕上渲染，這通常會帶來大量的渲染資料。
2 把所有的字元畫在一張貼圖上，然後在渲染的時候，每個字元就是乙個正方形（倆三角形），然後編碼每個找到合適的貼圖座標給這個正方形貼圖，使得貼的圖就是那個大字元圖上這個字元的影象，這種方法需要為每個字元預先編碼他們的貼圖座標。顯然這種方法更好一些，三角數目會少很多。
一般的字元渲染包括gui的渲染一樣都是採用第二種方法嗎，但是他有一些效率不高的地方，比如字元可能會要經常變化，那麼向管線要頻繁提交定點資料。因此針對這個就有一些優化的餘地：
1.將對視訊記憶體back buffer的lock方式設為discard方式，這種方式是d3d支援的一種方式，一種解決cpu的提交和gpu的渲染對backbuffer的訪問衝突的策略，正常情況當cpu提交給gpu的backbuffer要對其修改時，如果發現這塊快取恰巧正在gpu用於渲染給前快取，那麼提交會被打回，也就是這幀渲染不成功，會卡幀，這個discard標記在頻繁的vertex buffer提交時使用，
它的意思是如果發現這塊快取恰巧正在gpu用於渲染給前快取，那麼標記這個快取為valid，這時gpu會立即將這片快取重建，並且會馬上允許cpu的提交，並渲染。這會最大化的允許cpu對字型這種字元gui這種可能頻繁變化vb的物體的提交。
2.正常包括字元資料的vb（vertex buffer）要包括位置、貼圖座標、顏色資訊。但是其實不用每次都提交這麼多資訊，可以把乙個估計的最大的字串的vb用乙個流通道a（d3d的stream channel）提交，每次變化字元時只要提交乙個唯位移或者合併縮放資訊到另乙個通道b就行了。也就是頻繁提交的只是b通道的較少的資料。
3還可以利用d3d的instance技術，即把字元做成instance 那麼每次更改字元資訊，只提交字元的位置就行了，當然23都要使用shader實現。
4.有時為了實現字元或gui的上下層效果，需要有乙個層數的資訊，這個可以利用位置向量的z支來表示。
5.為了節省渲染資源提高效率，字元和gui這種不涉及到3d變換的表層物件，通常直接提交的是clip空間的座標，螢幕座標xy對應的剪裁座標計算公式為cx=-1+x*(2/screen_width) cy=1-y*(2/screen_height).在d3d的固定管線中就等於直接提
交d3dfvf_xyzrhw格式的vb，他不執行定點變換。
超級新手理解的字型渲染
所謂字型渲染，就是把指定的字形用畫素表示出來，由於大部分顯示裝置的畫素都是方形或長方形的小格仔，所以也叫柵格化。字形是一種特殊的圖形，專門用來表示字元，所以字型渲染也是圖形渲染的重要組成部分，屬於計算機圖形學範疇。渲染方式本身與字型原型設計有直接關係，所以先說說字型的設計方式。大體上字型設計可以分成...
安卓字型渲染器
必須能處理數量巨大的字型 必須能處理數量巨大的字形 必須最大化地減小紋理浪費 渲染速度必須夠快 在高階和低端機型上必須效果一致 在任何驅動 gpu組合上都必須完美執行 android.text.建立風格化文字和文字布局的類集合 android.graphics.paint，文字測量 android....
css字型，字元
中文名 英文名unicode unicode 2 mac os 華文細黑 stheiti light stxihei 534e 6587 7ec6 9ed1 華文細黑 華文黑體 stheiti 534e 6587 9ed1 4f53 華文黑體 華文楷體 stkaiti 534e 6587 6977 ...