僅個人筆記用；因網(wǎng)上相關(guān)資料過少，再加上翻墻困難，希望發(fā)上來能幫到一些人。

沒想到，整個小玩具，會出現(xiàn)如此之多的問題。

做一個小項目，在處理漢字顯示時，意外出現(xiàn)了一些問題，遂將解決過程寫在這里

關(guān)于導(dǎo)入字體……

根據(jù)文章長度，你大致可以推斷：這幾個對渲染漢字而言，用處相對有限。

第一個函數(shù)，暫且不考慮其作用。

普通的LoadFont的默認(rèn)參數(shù)，讓其大多數(shù)情況下直接被Pass。畢竟，只能錄入堪堪兩百字啊

但是LoadFontEx意外地不能解決問題。LoadFont與LoadFontEx，通過把字體轉(zhuǎn)化為圖片，存入顯存，以加快渲染，這是挺聰明的辦法。

前提是，glyphCount還只是幾百。

不然，直接內(nèi)存爆炸。(在fontSize=64時內(nèi)存占用達(dá)到GB級)

(畢竟?jié)h字字體動輒幾萬字，再加上Raylib這個笨蛋用的是Texture存儲的字體圖片，而非每1bit對應(yīng)一像素的處理)

接下來，我們看到這兩個函數(shù)。第一個函數(shù)……關(guān)鍵詞：XNA（這不就是之前的策略嗎）

第二個函數(shù)，關(guān)鍵詞：MemoryBuffer

換句話說，我們似乎可以把字體文件存在內(nèi)存里，然后轉(zhuǎn)化成具體的Font

相比，性能有所下降，但是占用內(nèi)存及大幅度下降

但是第二個函數(shù)怎么用呢……似乎沒能看到Example，自己隨便玩玩，沒想到成了

（其中，16375136為字體占磁盤空間的大?。?/p>

然后，質(zhì)的飛躍，發(fā)生了——

前者用LoadFontFromMemory實現(xiàn)，后者用LoadFontEx實現(xiàn)。文本包含中文。

前者CPU占用率相較后者低15%，內(nèi)存占用低87%，能耗水平等均遠(yuǎn)勝過后者

這個故事告訴我們：

傻孩子們，快跑啊，這可不興打表！

????????????????????????????????????????????????????——誰告訴我打表拿省一的來著

說到底，一切算法都還是有適用區(qū)間的嘛——顯然，Raylib的作者似乎沒有想到，會有一個頂級憨批，用最原初的函數(shù)，打開一個一個65536個字的字體文件。