向量化作業系統介面，為什麼很難實現？

1樓：姜恆

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

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

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

2樓：Xana Hopper

首先乙個，如果顯示裝置不是向量化的，這樣向量化沒有任何意義。

其次，你所說的向量化，就是系統內部資訊最大化，每乙個bit都是最優用的，可以利用圖形學演算法等生成最終顯示結果……這，不是很多系統已經做到了麼，最典型的不就是OS X的QE/CI麼……內部圖形都是向量的，交給系統底層柵格化，你就看到了麼。

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

3樓：Ivony

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

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

結論:全面向量化不能提高作業系統效能

作業系統並非畫素描述UI

作業系統支援向量輸出，如印表機。但顯示器不支援向量輸出

4樓：陳甫鵃

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

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

分離物理座標和邏輯座標。

系統可以暴露物理座標和邏輯座標，但是程式設計師僅僅允許操作邏輯座標，邏輯座標到物理座標的轉換只能交給系統完成。

作業系統可以處理邏輯座標系和物理座標系範圍不一致的情形。

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

但是向量化有三個弱點，具體地說是兩個限制和乙個不相容。向量化只適合描述那些線段可以用簡單公式描述的圖形。如果圖形中線條極其複雜則線段儲存資料會大增，反而加大資料量。

另外複雜的線段會加大圖形系統的解析難度，拖慢系統表現。畢竟系統還是要負責將公式轉化為線段之後計算需要在螢幕上填充的畫素數目。

向量化不適合描述色彩。色彩填充區域的基本操作，主要是滲透和渲染，其實很難用有限的數學公式表示。所以純向量圖形往往只能表現相對簡單的色彩變化，碰上覆雜的色彩表現要求時基本上只能一邊涼快去了。

現代美術創作手段仍然是基於畫素的。比如影視後期製作和美術，人們仍然是在乙個指定範圍的空間創作才會有確定的表現力。所以現在Mac上的圖示其實還是畫素圖，因為隨意縮放（特別是縮小）後的效果根本無法保證。

另乙個佐證是字型的hinting。熟悉字型製作的同學們都知道的乙個基本常識是即便是向量字型也有適合的顯示範圍，放得過大之後字型會變瘦，縮得過小則縮成一塊，觀感上無法滿足要求。

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

現在回過頭來看Google地圖。地圖是一種很適合向量化的資料資源。它的圖形基本上都可以用貝賽爾曲線或者樣條曲線描述（道路線條其實不需要100%地與真實地形吻合），而且需要的顏色也只是單色色塊，反過來它還需要大量的縮放操作。

考慮到現在計算裝置（包括移動裝置）的計算速度，這簡直是天生就該用向量描述的資料啊。

5樓：

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

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

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

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

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