前幾天的BLOG中說了一些我的3D引擎GUI的渲染部分原理，這幾天做到ListCtrl控件的時候，當我添加很多Item進去的時候（幾乎滿屏的12Px漢字，一個漢字兩個三角形，相當于上萬個三角形了），FPS降得嚇人，Debug版只有18FPS，Release版也只有60FPS。。優化、優化、還是優化！優化之后，FPS終于達到了令人滿意的500FPS左右了。且聽我慢慢說來。
首先是用我的引擎內部剖析分析了代碼的瓶頸（Profile這東西真的有用啊，讓我很容易就找到了慢的原因，參見GPG3 1.17《實時的層次化性能評測》），發現處理時間主要被Cache算法和渲染兩部份占了，于是，我在想，渲染慢是正常的（當時的想法比較弱智，后文有術），所以，我打算從Cache算法著手。首先是優化了ListCtrl的Cache算法，把那些在屏幕外的Item的Visible屬性設置成false（我的算法中Visible為false，Cache部分算法就直接跳過），于是速度一下子就上來了，Release版本達到了130FPS。但是，還是慢啊。怎么辦？剖析之后，發現大部分的處理時間都集中在渲染部分，我之前的想法是渲染慢是正常的，所以暫時無法解決。。。
下班的時候，出去遛了一圈，路上突然想到了我渲染算法中另外一個跟渲染速度有關的東西，動態修改頂點數據！難道是這里的原因？回來后馬上測試，把動態修改的代碼屏蔽，直接每幀渲染10000三角形，媽呀，1000＋的FPS！完全否定了我之前的想法（渲染慢是正常的），唉，想想也是，每秒千萬、上億個三角形生成速度的顯卡，對于區區一萬個三角形怎么會慢呢...既然找到原因，就要優化啊，現在找到原因是因為動態修改頂點導致，想到了以前看過一篇文章說頂點數據存儲的位置（即CreateVertexBuffer的D3DPool參數），說到做到，把原來的D3DPOOL_MANAGED改成D3DPOOL_SYSMEMORY，哇，速度一下子提升到360FPS左右！想起來原因也是簡單的，既然要每幀Lock這么多數據，那么頂點數據需要從顯存->CPU處理，然后CPU提交回顯存，總線交換也太頻繁了，如果改成SYSMEMORY的話，就只需要從CPU->顯存就可以了。
然后我又想，有沒有更好的優化方法？答案是有的。。最快的修改內存數據的方法是什么？當然是直接讀寫內存啊！那么我想到了DrawPrimitiveUP！把頂點數據直接new出來，然后DrawPrimitiveUP提交！改成這樣后，速度再度提升！達到驚人的500FPS！
最后，我把DrawPrimitiveUP改成DrawIndexedPrimitiveUP，那么頂點數量也減少了。但是奇怪的是速度缺沒有更快，反而慢了一點點（慢了5～10FPS左右），但是，我用了DrawIndexedPrimitiveUP，我之后還有更好的優化算法準備實現。通過DrawIndexedPrimitiveUP，但是還沒做好。。所以先賣個關子了。明天搞好的話再寫Blog。
唉，回頭看了下自己寫的東西，亂七八糟。都不知道有沒有人看得懂啊。不管了。知之為知之，不知為不知吧。呵呵，看不懂的請評論一下。
寫代碼去了～～