矢量化操作系統界面，為什麼很難實現？

01-12

Google Maps 進行矢量化後，佔用流量、讀取速度都有了大幅度提升。如果操作系統界面也進行矢量化，那麼會不會也能帶來類似的提升？如果有困難，具體難在哪兒？

我平時一般不會把話說絕，但整個操作系統圖形介面上全面矢量化是很少的幾個絕無可能的事情。

操作系統界面的界面元素矢量化其實是早就實現了的。而且基本上所有我們知道的現代圖形系統都能做到。在我看來矢量化的圖形系統最重要也基本上是僅有的要件就是三點：

分離物理坐標和邏輯坐標。
系統可以暴露物理坐標和邏輯坐標，但是程序員僅僅允許操作邏輯坐標，邏輯坐標到物理坐標的轉換隻能交給系統完成。
操作系統可以處理邏輯坐標系和物理坐標系範圍不一致的情形。

有了矢量圖形我們就可以避免直接指定像素數據，而只需要告訴計算機我們要的坐標系，以及要畫的線段的少數幾個關鍵數據（直線段是起點和重點坐標，貝賽爾曲線是起點終點和中間錨點），當然數據的傳輸量要小很多。這實際上是把點陣繪圖的任務交給系統完成，畢竟屏幕還是基於像素的。

但是矢量化有三個弱點，具體地說是兩個限制和一個不兼容。

矢量化只適合描述那些線段可以用簡單公式描述的圖形。如果圖形中線條極其複雜則線段存儲數據會大增，反而加大數據量。另外複雜的線段會加大圖形系統的解析難度，拖慢系統表現。畢竟系統還是要負責將公式轉化為線段之後計算需要在屏幕上填充的像素數目。
矢量化不適合描述色彩。色彩填充區域的基本操作，主要是滲透和渲染，其實很難用有限的數學公式表示。所以純矢量圖形往往只能表現相對簡單的色彩變化，碰上複雜的色彩表現要求時基本上只能一邊涼快去了。
現代美術創作手段仍然是基於像素的。比如影視後期製作和美術，人們仍然是在一個指定範圍的空間創作才會有確定的表現力。所以現在Mac上的圖標其實還是像素圖，因為隨意縮放（特別是縮小）後的效果根本無法保證。另一個佐證是字體的hinting。熟悉字體製作的同學們都知道的一個基本常識是即便是矢量字體也有適合的顯示範圍，放得過大之後字體會變瘦，縮得過小則縮成一塊，觀感上無法滿足要求。

所以簡而言之，所有鼓吹圖形系統全面矢量化的同學們，你們該去補補美術課啦。

現在回過頭來看Google地圖。地圖是一種很適合矢量化的數據資源。它的圖形基本上都可以用貝賽爾曲線或者樣條曲線描述（道路線條其實不需要100%地與真實地形吻合），而且需要的顏色也只是單色色塊，反過來它還需要大量的縮放操作。考慮到現在計算設備（包括移動設備）的計算速度，這簡直是天生就該用矢量描述的數據啊。

OS X 的界面是矢量化的。不過矢量化這個定義不很準確。終究有些東西不適合矢量化。

更新：突然發現 @武廣鑫說的很對。現代操作系統真的不是矢量化的。我們說的基於 PDF 的 OS X 圖形系統都是實現於各種用戶態庫和 driver 中的。而系統級的 compsitor (WindowServer) 是基於像素的。究其原因，矢量化又多種模式，比如 PDF 的畫筆模式，OpenGL 的 vertex 模式。作為操作系統實在無法找到一種 one-size-fit-all 的模式。所以操作系統都是處理像素的，把矢量化留給各種庫。但是從功能角度說，操作系統確實是提供各種矢量化庫給開發者選擇的。

看了 @陳甫鵃的答案，覺得強調的重點與我理解的不同。矢量化的重點不是什麼技術上的難題，其實 OS 的窗口管理器完全可以改寫成直接從 app 那裡獲取 vertex，法線，色彩漸變信息。而是 policy 的問題。重點在於，矢量化本身是 application-specific 的。「這裡有一個三角形，那裡有一個 Bezier 曲線」，這些應該是 app 了解的 knowledge。而操作系統只應該了解怎麼顯示 app 生成的 bitmap 就好。這就像 toolkit，本來認為可以由操作系統負責（每個 control 都是一個窗口），後來發現交給 user land library 就好，操作系統根本不管什麼是 toolkit。

從前是圖形硬體能力有限，直接用像素內容的位平面緩存做為輸出源，只要DAC帶寬做上去就行了，比較好搞。以現在的硬體能力，整個系統直接輸出 OpenGL 原語也沒啥問題，倒是軟體系統的慣性了。

不過，很久以前操作系統就已經跨過了讓應用直接操縱圖形緩存的階段，GDI/X/Quartz提供給應用的都是點線面各種圖元，不大直接 bitblt 了，DirectX 算是開了一把倒車，弄得一堆人要現學現寫 DDA、wuline 。

如果不是蘋果地圖，Google 還不知道啥時候才出會把矢量地圖推出來呢，除了省流量，也確實更快。一屏地圖往往由很多塊小圖片拼成，上傳給顯卡時帶寬就那麼多，傳這些像素的數據量矢量地圖的一堆線段參數不知道大了多少倍，iOS 的話還得很跟整個界面複合。

而絕大部分應用，其實界面已經是矢量描述+貼圖的方式了，如果用 Gradient 等手段來進一步減少背景圖，也會有提高，不過要不是界面堆了太多圖片的情況，總體效果感覺不到的。

矢量化的目的是降低流量，這跟操作系統的UI渲染半毛錢關係都沒有。

界面UI元素現在都是類矢量化的，但顯示器的原理決定了顯示輸出必須是像素點陣。

結論:

全面矢量化不能提高操作系統性能

操作系統並非像素描述UI

操作系統支持矢量輸出，如印表機。但顯示器不支持矢量輸出

CPU的矢量計算效率有限，雖然有相應的擴展指令，但是硬體上應該都是整數運算，浮點運算為基礎吧。

然後界面的顯示上來說，貌似沒聽說矢量顯示器這樣的東西～都應該是顯示點陣的吧～

編程方面，現有的語言，應該也是只能直接進行數值、邏輯運算還有邏輯處理，面向矢量做東西，好像不是很直接～

現在操作系統界面的很多元素，好像已經是矢量的了，比如字體，你給計算機換大字體，字體還是很清晰的顯示的。也有很多矢量的圖形格式。

但是，系統界面的某些其他元素，貌似不是很有矢量化的必要。至少目前來看，矢量化對計算量，編程量的代價還是大於帶來的好處。

Quartz、WPF、WinRT，都可以算是矢量化的界面。界面所有元素均可無級縮放而不會導致錯誤的顯示效果。

至於說非要所有地方都不出現像素，這就有點無聊了，沒有這麼定義矢量化界面的。

如果說按照Google Maps那個意義的矢量化，可以說所有系統都是矢量化的，包括老舊的GDI：它們的線條，在系統內部都是以線的方式表示的，而不是點陣圖。

首先一個，如果顯示設備不是矢量化的，這樣矢量化沒有任何意義。
其次，你所說的矢量化，就是系統內部信息最大化，每一個bit都是最優用的，可以利用圖形學演算法等生成最終顯示結果……這，不是很多系統已經做到了么，最典型的不就是OS X的QE/CI么……內部圖形都是矢量的，交給系統底層柵格化，你就看到了么。

至於你還期待什麼其他矢量化？我就想不到了