用 GDI+ 開發向量圖形編輯系統的經驗之談

因為一個項目（封裝盒型向量圖形編輯器），在經過對GDI、GDI＋、OpenGL、DirectX以及項目的實際需求綜合評估之後，我決定選擇 GDI+ (GDI Plus) 作為圖形開發的工具，因為以前從來沒有深入涉及過圖形的開發，項目開始的時候有點無從下手，經過一段時間的摸索，終於有了一點眉目，於是就開始了下面各個方面的工作：

1. GDI+如何擦除圖形以及其速度測試。

      在網上看到很多文章，決大部分圖形編輯器使用的都是C++之類的開發工具，然後直接調用GDI Windows API進行操作，圖形繪製的時候多數採用異或的方法，這樣速度很快，但是繪圖時有閃爍，也有採用雙緩衝的方式，避免圖形閃爍，但是速度稍微慢，占記憶體，而GDI+不支援異或繪圖，在微軟有關技術文檔中，他們的理由是：硬體愈來愈進階，速度不成為問題，而視覺享受是第一位的，以後的圖形編輯器都會採用雙緩衝，這是一個趨勢。

      1）從CodeProject等其他源碼網站上搜尋了很多原始碼如何通過雙緩衝結合滑鼠的操作進行映像的擦除，經過無數次的實驗，終於形成自己的代碼風格。大概原理如下：在記憶體中聲明兩個Bitmap，一個Bitmap用來進行及時的圖形繪製，一個Bitmap用來進行存放已有的圖形，在用滑鼠繪圖的過程中，直接把Bitmap拷貝到繪圖視窗所對應的Graphics上，這樣能提升繪圖的速度。

      2）速度測試就比較麻煩了，前後經過很多次，貫穿了整個開發過程，在我印象中因為速度問題引起的對象建模的基礎修改次數不下5次，在圖形編輯器中，速度不僅僅取決與GDI+還是GDI，更重要的是開發人員結合你所用的開發工具選擇合適的演算法。演算法大概要求，盡量避免用三角函數、平方根、除法；盡量用整數、加法、乘法。
         在開發中還發現一個有趣的現象，就是如果大量使用Structure也會導致資料賦值速度變慢，而Class則能在一定程度上提升資料賦值速度。但是看到.NET2.0中的提供的Point, Rectangle等都是結構，為什麼微軟會這樣做呢？後來插到有關的資料（一個曾經參與.NET開發，後來離開微軟，並攻擊.NET的人），微軟的.NET有很多個物件簡單的API的封裝，而且這些.NET對象的實現也是用C++來做的，就是說這些工具可以調用指標，而我所用的VB.NET不能操作指標，所以導致用Structure速度變慢。這個發現也導致了我的許多工作推倒重來。

2. 對象建模。
      這個很麻煩，一直到現在還在不斷修改物件模型，因為沒有經驗的原因，走了很多彎路。曾經參考過一個控制項VectorDraw，其協助裡面有完整的對象說明，圖元、座標系、標註等，看了以後很受啟發，經過不斷的摸索，也終於形成了自己的對象風格，現在這個Object Model可以很好地處理圖形的結構（檔案、圖層、圖元）、滑鼠操作、圖形參數化、零件、顯示和操作的速度。

   1）圖元確定。一般情況下基本圖元包含直線、矩形、（橢）圓、（橢）圓弧、曲線、標註（作為設計器一定要標註）
   2）圖元參數的儲存和處理。經過若干次的測試，發現最終直接把象素值儲存在圖元的參數中比較方便，但是像.NET2.0中的Rectangle，Point，Line等圖元只支援Single類型，而在實際操作過程中，比如縮放、旋轉、座標系變換後，Single資料類型的還原性很差，必須用Double才能處理，所以我把所有圖元參數全部用Double類型處理，雖然對計算效能有影響，但總的速度還可以接收。
   3）座標系。GDI+中的裝置座標系和我們正常使用的笛卡兒座標系有點不一樣，為了方便使用者在繪圖時的操作，我們必須在介面上給使用者顯示笛卡兒座標系，而在實際繪圖時使用裝置座標系。座標系對象也負責對這兩個座標系的資料進行一對一的轉換。
   4）映像拾取。不同的圖元，有不同最優的拾取演算法，比如線段，怎麼判斷滑鼠線段上，這個很有技巧性，演算法慢的和快的差幾十倍，後來選擇了一般常用的向量計算方法，據說1秒可以判斷100萬條直線，這個很牛，以此類推，很快解決了各個圖元的拾取演算法。

《未完待續》