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