大佬們好。
最近在改一個功能，將網路傳輸過來的實時圖片幀，重繪到界面形成影片。
在Model中系結View中的Image，每次接收之后更改Model中的ImageSource。
測驗了接收效率，基本能達到35+幀能滿足要求，但是在重繪的時候會比較卡 明顯不夠流暢，顯示重繪的就只有十來幀。
請問一下有沒有別的更好的實作方案？
uj5u.com熱心網友回復：
每次都更改一個圖片，如果這個圖片是十分大的圖片，當然此時的渲染將會很卡了有一個方法是構建圖片和顯示圖片放在不同的執行緒，這樣能提升一定的性能
將 BitmapImage 的構建到 EndInit 放在另一個執行緒，注意呼叫 Freeze 方法，然后放在主執行緒顯示，此時將可以使用兩個執行緒做圖片決議和顯示，預計能提升一些性能。另外對于圖片決議來說，大部分的顯卡都有對 jpg 的加速，剛好 WPF 是能用上這部分加速的，從性能提升的角度上說，如果能回傳 jpg 會更好。其次，如果每次不是全量的圖片重繪，也能提升一些速度，加入每次只是回傳增量的部分，通過 WriteableBitmap 的方式重繪部分，也能做到比較好的性能。我就是通過 WriteableBitmap 的形式重繪一個垃圾廠商給的攝像頭的內容，輕松在垃圾的cpu上重繪到了60赫茲
uj5u.com熱心網友回復：
感謝回復。
首先，我是通過同步方式進行轉換，因為格式比較奇葩，只能先用bitmap接收，然后用Image加載后，進行Endint和Freeze釋放空間，再通過事件委托將該image傳到記憶體的系結引數上。在freeze后，我計算過幀率，就是標題中所說的，35~45幀，看起來不是瓶頸。我傾向于是在加載圖片的時候處理不當或者達到了硬體瓶頸【沒有獨立顯卡】。
1、這里說的“回傳jpg”我不太明白是什么意思？是說介面嗎？
2、全量的圖片重繪 由于影片效果采集的是固定全量，如果我這邊還做圖片對比計算的話，可能作業量較大不太合適。
3、關于使用WriteableBitmap，意思是不使用系結，加載到圖片之后，通過WriteableBitmap填充界面的圖片嗎？
uj5u.com熱心網友回復：
1. 用 Bitmap 接收可以放在另外執行緒，這部分可以減少主執行緒卡頓2. 回傳 jpg 是因為渲染 jpg的性能相對快一點
3. 使用 WriteableBitmap 是重繪需要更改的地方，通過修改像素和問題 2 相同，需要你先計算哪些需要重繪
uj5u.com熱心網友回復：
可能我說的不是很清楚，傳過來的影片是一個二進制碼，我處理的方式是用bitmap的格式取出，然后再轉成可以顯示的imagesource。回傳jpg我沒看太明白什么意思？
剩下的兩點我試下，謝謝
uj5u.com熱心網友回復：
其實 Jpg 也是二進制，也就是服務器端回傳的二進制格式是 jpg 檔案
uj5u.com熱心網友回復：
用Image的WritePixels方法試試。uj5u.com熱心網友回復：
這個傳輸協議的二進制內容必須壓縮GZipStream 要是大圖嗝屁uj5u.com熱心網友回復：
public static BitmapImage LoadImg(string uri){
BitmapImage image = new BitmapImage();
image.BeginInit();
try
{
image.UriSource = new Uri(uri);
image.CacheOption = BitmapCacheOption.OnLoad;
RenderOptions.SetBitmapScalingMode(image, BitmapScalingMode.LowQuality);
image.EndInit();
}
catch (Exception ex)
{
return null;
}
return image;
}
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/184886.html