圖形裝置介面（英語：Graphics Device Interface，縮寫 GDI），這個字眼大概是我寫程式時最害怕看到的第一名！不只是如上的甚麼泛型錯誤，還包括莫名其妙出現的參數錯誤，或記憶體不足等等。因為這類錯誤的出現總是和你的程式邏輯無關，程式明明是對的，但是執行很多次之後就會忽然跳出這些錯誤？

昨天就為了一個專案需要快速大量的影像讀檔與顯示的功能，與RD一起傷腦筋，程式怎麼改都會出現不同的，與GDI相關的奇怪錯誤！譬如參數明明是固定的，跑幾百次之後就忽然說參數錯誤？又如打開工作管理員監看記憶體用量明明就很正常，沒有暴增，但是程式跑一半忽然就說記憶體不足？

「理論」上網路資訊都會說跟檔案權限設定或記憶體釋放有關，但是我的經驗是即使你都做到了這些事情，不穩定的錯誤也還是常常發生！我想網路上那些分享者，也都沒像我們這樣快速大量的處理連續動態的影像吧？這種時候我們通常只能用Try Catch之類的錯誤捕捉機制忽略錯誤，就是當作天災，偶爾發生就放棄那一筆資料算了！只要不當機或影響整體運算結果就沒事。

但是來自GDI的錯誤不會讓你這麼容易過關，忽略錯誤之後並不會保證完全恢復，常常會繼續同一錯誤，即使程式沒當掉也變成在空轉！該拿它怎麼辦呢？我也沒有絕對有效的解藥，但是之前都是怎麼過關？或是說混過去的呢？其實是我摸到了GDI的一個脾氣：

對於釋放記憶體的指令如Dispose或GC.Collect之類的，它通常愛理不理，但是實質的「休息」常常很有用！就是Thread.Sleep(10)之類的，讓它做完某個常出現意外的指令之後直接休息幾個毫秒！似乎多出這幾毫秒的休息緩衝時間，GDI底層的一些記憶體轉移動作就可以比較穩定做到好了？

昨天到下班前都還沒解決的問題，今天早上寫了模擬程式繼續作壓力測試，好像合理的解方還是「休息」？我還是無法完全保證它永遠不出現GDI錯誤，但至少要能讓錯誤頻率降低，還要可以在忽略錯誤後恢復正常運轉，看起來我的模擬是做到了！待會上班再和RD做完整實測吧！

如維基百科所言，GDI就是與繪圖周邊硬體設備溝通的程式模組，或許它為了求快速，而且很多硬體不是可以像作業系統內的各軟體模組一樣容易精準合作，當硬體反應來不及應付軟體指令時，就卡關出錯了！理論上那些記憶體釋放的指令應該要有效，但實際上常常沒用，這就是GDI還需要努力的方向了！

那我們現在該怎麼過日子呢？大概就像擔任公司的老闆一樣，不要將員工操過頭了！該放假時就要放假的概念吧？別讓員工累到生病，或加班加到心情很差！做完苦差事一定要記得給它Thread.Sleep一下囉！