這些更新涵蓋了多個(gè)關(guān)鍵庫(kù)和工具，每個(gè)都在軟件開(kāi)發(fā)和應(yīng)用程序中扮演重要角色。讓我們簡(jiǎn)要地介紹一下每個(gè)庫(kù)的主要功能和更新內(nèi)容：

1. Pango 1.50.14.0：
2. 功能：Pango 是一個(gè)用于布局和渲染文本的庫(kù)，支持多種語(yǔ)言和復(fù)雜文本排版。
3. 更新：此版本可能包括性能優(yōu)化、Bug修復(fù)和新功能增強(qiáng)。
4. Cairo 1.17.8.0：
5. 功能：Cairo 是一個(gè)2D圖形庫(kù)，支持多種輸出設(shè)備，用于繪制矢量圖形。
6. 更新：更新可能包括性能改進(jìn)、Bug修復(fù)和新的渲染功能。
7. Fontconfig 2.14.2.0：
8. 功能：Fontconfig 是一個(gè)字體配置和定制庫(kù)，用于管理系統(tǒng)中可用的字體。
9. 更新：可能包括新的配置選項(xiàng)、Bug修復(fù)和字體渲染的優(yōu)化。
10. Freetype 2.12.1.0：
11. 功能：Freetype 是一個(gè)用于渲染字體的庫(kù)，支持TrueType、OpenType等字體格式。
12. 更新：通常包括字形優(yōu)化、Bug修復(fù)和對(duì)新字體格式的支持。
13. Iconv 1.17.0.0：
14. 功能：Iconv 是一個(gè)用于字符編碼轉(zhuǎn)換的庫(kù)。
15. 更新：可能包括新的編碼支持、性能改進(jìn)和Bug修復(fù)。
16. Intl 0.21.1.0：
17. 功能：Intl 是一個(gè)用于國(guó)際化和本地化的庫(kù)，提供了多語(yǔ)言支持。
18. 更新：可能包括新的語(yǔ)言支持、性能優(yōu)化和Bug修復(fù)。
19. Glib 2.76.3.0：
20. 功能：Glib 是一個(gè)通用的系統(tǒng)庫(kù)，提供了數(shù)據(jù)結(jié)構(gòu)、線(xiàn)程支持等功能。
21. 更新：可能包括性能改進(jìn)、新功能添加和Bug修復(fù)。
22. Harfbuzz 8.0.0.0：
23. 功能：Harfbuzz 是一個(gè)開(kāi)源的文本整形引擎，用于正確地排列和渲染復(fù)雜文本。
24. 更新：可能包括對(duì)新語(yǔ)言和字體的支持、性能改進(jìn)和Bug修復(fù)。
25. Libexpat 2.5.0.0：
26. 功能：Libexpat 是一個(gè)輕量級(jí)的XML解析庫(kù)。
27. 更新：可能包括對(duì)XML標(biāo)準(zhǔn)的新支持、性能改進(jìn)和Bug修復(fù)。
28. Libffi 3.4.4.0：
29. 功能：Libffi 是一個(gè)用于調(diào)用C函數(shù)的接口庫(kù)。
30. 更新：可能包括新的平臺(tái)支持、性能改進(jìn)和Bug修復(fù)。
31. Libpng 1.6.39.0：
32. 功能：Libpng 是一個(gè)用于處理PNG圖像格式的庫(kù)。
33. 更新：可能包括新的壓縮算法、性能改進(jìn)和Bug修復(fù)。
34. Zlib 1.2.13.0：
35. 功能：Zlib 是一個(gè)數(shù)據(jù)壓縮庫(kù)，廣泛用于文件壓縮和解壓。
36. 更新：可能包括新的壓縮算法、性能優(yōu)化和Bug修復(fù)。
37. OpenCV 4.8.0：
38. 功能：OpenCV 是一個(gè)開(kāi)源的計(jì)算機(jī)視覺(jué)庫(kù)，用于圖像處理、計(jì)算機(jī)視覺(jué)和機(jī)器學(xué)習(xí)。
39. 更新：可能包括新的算法、性能改進(jìn)、Bug修復(fù)和對(duì)新硬件平臺(tái)的支持。

這些更新不僅增強(qiáng)了每個(gè)庫(kù)的功能和性能，還反映了持續(xù)改進(jìn)和Bug修復(fù)的努力，以提供更穩(wěn)定、更高效的開(kāi)發(fā)和運(yùn)行環(huán)境。

艷艷 發(fā)自 凹非寺
量子位 報(bào)道 | 公眾號(hào) QbitAI

提到PNG，大多數(shù)人都不會(huì)感到陌生。

這種位圖格式在圖像領(lǐng)域使用頻率僅次于JPEG。

然而在“解碼PNG”這件事上，23年來(lái)主流的工具是一個(gè)叫做libpng的標(biāo)準(zhǔn)庫(kù)。

但最近，一款號(hào)稱(chēng)“世界上最快的PNG圖像解碼器”誕生了，速度是“老大哥”的1.22-2.75倍！

除了速度方面的優(yōu)勢(shì)之外，更重要的一點(diǎn)，極其安全。

最快的PNG圖像解碼器

與用C語(yǔ)言為底層的libpng不同，這款PNG圖像解碼器采用的是Wuffs。

Wuffs是一種內(nèi)存安全的編程語(yǔ)言(也是用這種語(yǔ)言編寫(xiě)的標(biāo)準(zhǔn)庫(kù))，用于安全處理不受信任的文件格式。

包括解析、解碼和編碼圖像，音頻，視頻，字體等。

Wuffs不是一種通用編程語(yǔ)言。它是用來(lái)編寫(xiě)庫(kù)的，完整的程序需要將Wuffs與另一種編程語(yǔ)言結(jié)合使用。

尤其是需要同時(shí)考慮性能和安全性的時(shí)候。

ps. 機(jī)智的你發(fā)現(xiàn)了嗎，Wuffs其實(shí)就是Wrangling Untrusted File Formats Safely的縮寫(xiě)。

不過(guò)它以前叫Puffs，至于為什么將Puffs(parsing)改為Wuffs(wrangling)，留給你們自己去想象～

那么，解碼速度快至2.75倍，怎么做到的？

Wuffs通過(guò)SIMD加速方案，8字節(jié)寬的輸入和復(fù)制，一次將整個(gè)圖像進(jìn)行位扭曲和zlib解壓縮到一個(gè)大的中間緩沖區(qū)來(lái)實(shí)現(xiàn)高性能。此法替代了此前的一次一行（小塊重復(fù)壓縮）的方式。

這“一包帶走”的操作需要更多的中間存儲(chǔ)，但能解碼的圖像數(shù)量也更多了。

具體咋回事兒呢？

我們知道，PNG圖像格式編/解碼基于以下三方面：

• CRC-32和Adler-32兩種校驗(yàn)和算法
• DEFLATE壓縮
• 二維過(guò)濾

Wuffs對(duì)這其中的每一步都進(jìn)行了優(yōu)化。

首先，對(duì)兩種校驗(yàn)和算法施以SIMD加速技術(shù)。

SIMD是一種采用一個(gè)控制器來(lái)控制多個(gè)處理器，同時(shí)對(duì)一組數(shù)據(jù)中的每一個(gè)分別執(zhí)行相同的操作從而實(shí)現(xiàn)空間上的并行性的技術(shù)。

其次，0.2版本W(wǎng)uffs具有與zlib庫(kù)一樣的DEFLATE實(shí)現(xiàn)，而0.3版Wuffs為現(xiàn)代CPU（具有64位未對(duì)齊加載和存儲(chǔ)）添加了兩個(gè)重要的優(yōu)化：8字節(jié)區(qū)塊輸入和8字節(jié)區(qū)塊輸出。

DEFLATE是同時(shí)使用了LZ77算法與哈夫曼編碼的一個(gè)無(wú)損數(shù)據(jù)壓縮算法。

對(duì)于Wuffs，8字節(jié)區(qū)塊輸入設(shè)計(jì)的每個(gè)內(nèi)部循環(huán)一次讀取64位可使DEFLATE微基準(zhǔn)加速多達(dá)1.3倍。

而8字節(jié)區(qū)塊輸出設(shè)計(jì)將副本長(zhǎng)度舍入為8的倍數(shù)可以使DEFLATE微基準(zhǔn)提高多達(dá)1.48倍。

此外，DEFLATE涉及寫(xiě)入目標(biāo)緩沖區(qū)和寫(xiě)入緩沖區(qū)邊界的問(wèn)題。

（經(jīng)典的“緩沖區(qū)溢出”安全漏洞，類(lèi)似于從懸崖上奔跑，如何不落入鯊魚(yú)口中）。

此方面，Wuffs使用和libpng相似的藍(lán)/紅雙重實(shí)現(xiàn)技術(shù)。

藍(lán)/紅雙重實(shí)現(xiàn)技術(shù)：一種快速的“藍(lán)色”解壓縮（在距緩沖區(qū)末端至少258個(gè)字節(jié)或更多字節(jié) 時(shí)）以及一種緩慢的“紅色”解壓縮（反之）技術(shù)。

以前面的從懸崖上奔跑做比喻，就是在離崖邊還遠(yuǎn)時(shí)盡可能得快跑，離崖邊很近時(shí)減速剎車(chē)。

但同樣的技術(shù)，為什么Wuffs更快？

因?yàn)樗芤淮螌缀跛袃?nèi)容（eg. 300×200 RGB圖像的像素的99％以上）解壓縮到一個(gè)大的中間緩沖區(qū)中，而不是一次只壓縮一行到一個(gè)小的、可重復(fù)使用的中間緩沖區(qū)中。

如圖所示，幾乎所有內(nèi)容現(xiàn)在都在“藍(lán)色”區(qū)域中解碼。

這本身就比“紅色”區(qū)域快。

而且在藍(lán)色代碼和紅色代碼之間交替時(shí)，Wuffs也避免了任何指令高速緩存或分支預(yù)測(cè)變慢的情況。

最后，雖然Wuffs和libpng都具有PNG二維過(guò)濾的SIMD實(shí)現(xiàn)。

但是因?yàn)閘ibpng將任何自分配的像素行緩沖區(qū)對(duì)齊到最適合SIMD的邊界時(shí)，對(duì)齊這步操作會(huì)影響SIMD指令的選擇和性能。

而Wuffs對(duì)緩沖區(qū)對(duì)齊的承諾較少，部分原因是Wuffs不具有分配內(nèi)存的能力，但主要還是因?yàn)橐淮稳拷鈮嚎s時(shí)，zlib壓縮要求放棄例如每行開(kāi)頭4字節(jié)的對(duì)齊。

為什么說(shuō)最安全？

與Go或Rust不同，Wuffs的內(nèi)存安全是在編譯時(shí)強(qiáng)制執(zhí)行的，而不是通過(guò)插入運(yùn)行時(shí)再檢查。

（ ps.運(yùn)行時(shí)安全檢查也可能會(huì)影響性能。）

此外，在處理不受信任的（第三方）PNG圖像時(shí)，沙盒和多進(jìn)程體系結(jié)構(gòu)可以提供額外的深度防御。

在上一節(jié)描述的三步優(yōu)化技術(shù)也可用來(lái)給現(xiàn)有的libpng、Go/Rust PNG庫(kù)等打補(bǔ)丁。

然后就有網(wǎng)友說(shuō)這樣一來(lái)Wuffs還是不是最快的就難說(shuō)了……但開(kāi)發(fā)者表示至少在安全性方面，Wuffs No.1沒(méi)得說(shuō)。

最后，Wuffs版本0.3.0-beta.1剛剛發(fā)布，但從目前的功能來(lái)看，它還不支持顏色空間或伽馬校正。

有興趣的讀者可訪(fǎng)問(wèn)參考鏈接[6]。

參考鏈接：

[1]https://nigeltao.github.io/blog/2021/fastest-safest-png-decoder.html
[2]https://groups.google.com/g/wuffs/c/sAcU-Uvjns8
[3]https://news.ycombinator.com/item?id=26714831
[4]https://zhuanlan.zhihu.com/p/196797277
[5]https://github.com/google/wuffs/blob/main/doc/note/memory-safety.md

[6]https://github.com/google/wuffs/tree/v0.3.0-beta.1/example

— 完 —

量子位 QbitAI · 頭條號(hào)簽約

關(guān)注我們，第一時(shí)間獲知前沿科技動(dòng)態(tài)