這是我是否應該修正以某種方式這個問題,而不是開始一個新的對我剛纔的問題Speeding Up Image Handling影響因素時使用GDI +
道歉的後續來渲染圖像。
我已經嘗試過各種不同的事情來加速在屏幕上繪製圖像。
我認爲壓縮圖像直到它變小會產生影響。但是,儘管這可能爲該對象節省內存,但我認爲它對繪製需要多長時間沒有任何影響。我試圖將圖像轉換爲JPEG並使用100%壓縮。但是,雖然這會產生塊狀圖像,但不會影響繪圖時間。我現在認爲這是因爲得到渲染的像素數量沒有被改變這
我試着將調色板減少到256色。這使得尺寸更小,因爲它使用每像素較少的字節數,但似乎不影響在屏幕上的繪圖。我曾認爲減少每像素GDI +必須處理的字節可能會節省一些時間,但目前爲止我還不夠。
所以,我浪費我的時間看壓縮和調色板?
我假定所花費的時間將受到要繪製的像素數量(寬x高)的影響,並且我調整了圖像的大小以匹配屏幕上顯示的像素大小。我認爲這是一個有影響的東西....
我看過如何停止圖像的自動縮放 - 我的縮放停止或圖像仍然可以自動縮放時呈現?
我想知道是否可以用p/Invoke或其他API調用(我承認我不太瞭解)替換DrawImage調用。
奇怪的是,在調查如何在圖形引擎中實現BitBlt時,我偶然發現了一個名爲RenderQuality的屬性,該屬性與deviceContext關聯。通過應用LowQuality同時呈現圖像和HighQuality來處理所有其他問題,我的表現問題似乎已經消失。所以看來這一次的旅程可能終於結束了...... – ScruffyDuck