WPF 每次 BufferToBitmap 的时候都创建新的 WriteableBitmap 岂不是完全没发挥 WriteableBitmap 的性能 about usbcamera

[secile]

Hello, I read your issue translated by DeepL.

If I am making video playback application, your opinion - create single WriteableBitmap and redraw every frame updated - is good solution.
But this library is for USB camera frame capture application, I think my approch is reasonable.

For instance, when you execute GetBitmap() two times with some interval, first image must be different from second image.
However, if I implement your approach, I would get the same image.

If you have a different opinion, please let me know.

[yangjieshao]

暴露 获取byte[]的方法
相机启动的时候通过 GetBitmap() 获取 WriteableBitmap
之后定时通过 GetBuffer() 获取帧byte[]
使用 UpdataWritableBitmap 更新 writableBitmap
这样相较在 wpf 上使用 camera.SetPreviewControl(handle, new Size(320, 240)) 的好处是 不用嵌入winform控件 对异形画面更友好 ,性能也比每次通过GetBitmap更新画面更好 也没有多余的GC浪费

public static void UpdataWritableBitmap(byte[] imgBuffer, ref WriteableBitmap writableBitmap)
        {
            if (imgBuffer != null
                && imgBuffer.Length > 0
                && writableBitmap != null)
            {
                writableBitmap.Lock();
                Marshal.Copy(imgBuffer, 0, writableBitmap.BackBuffer, imgBuffer.Length);
                writableBitmap.AddDirtyRect(new System.Windows.Int32Rect(0, 0, writableBitmap.PixelWidth, writableBitmap.PixelHeight));
                writableBitmap.Unlock();
            }
        }

基于你的旧版代码的修改

我的建议是 暴露 获取byte[]的方法 由使用的人判断在wpf程序中是使用 UpdataWritableBitmap 还是 SetPreviewControl 来播放实时画面
毕竟嵌入winform控件的方式会导致很多wpf的效果没法实现

[secile]

Thank you for your response.

I'm now understand that your issue's purpose is to improve a preview under WPF.
Using SetPreviewControl requires WinForm control and it can not use WPF's merit.
Using GetBitmap requires a lot of GC and less performance.

I usually do not use WPF, so I didn't notice the problem.
I will consider how to deal with the problem.

[secile]

This is my working note.

target app: SampleProject/UsbCameraWpf

1. use SetPreviewControl
   

2. use DispatcherTimer and GetBitmap()
   

conclution:

• SetPreviewControl uses less memory and less GC.
• It seems no difference of CPU performance.

[secile]

This is my working note.

There are 2 lines that allocate memory.

1. var result = new WriteableBitmap(width, height, dpi, dpi, PixelFormats.Bgr24, null);
2. var pixels = new byte[lenght];

private static BitmapSource BufferToBitmap(byte[] buffer, int width, int height, int stride)
{
    const double dpi = 96.0;
    var result = new WriteableBitmap(width, height, dpi, dpi, PixelFormats.Bgr24, null); --- (1)

    var lenght = height * stride;
    var pixels = new byte[lenght]; --- (2)

    // copy from last row.
    for (int y = 0; y < height; y++)
    {
        var src_idx = buffer.Length - (stride * (y + 1));
        Buffer.BlockCopy(buffer, src_idx, pixels, stride * y, stride);
    }

    result.WritePixels(new Int32Rect(0, 0, width, height), pixels, stride, 0);

    // if no Freeze(), StillImageCaptured image is not displayed in WPF.
    result.Freeze();

    return result;
}

[secile]

This is my working note.

as to No.2,
If I change below, (do not allocate memory everytime).

private static byte[] pixels = null;
private static BitmapSource BufferToBitmap(byte[] buffer, int width, int height, int stride)
{
    const double dpi = 96.0;
    var result = new WriteableBitmap(width, height, dpi, dpi, PixelFormats.Bgr24, null);

    var lenght = height * stride;
    if (pixels == null) pixels = new byte[lenght];

    // copy from last row.
    for (int y = 0; y < height; y++)
    {
        var src_idx = buffer.Length - (stride * (y + 1));
        Buffer.BlockCopy(buffer, src_idx, pixels, stride * y, stride);
    }

    result.WritePixels(new Int32Rect(0, 0, width, height), pixels, stride, 0);

    // if no Freeze(), StillImageCaptured image is not displayed in WPF.
    result.Freeze();

    return result;
}

• less GC.
• Process Memory increased. (I think this is result of less GC, so we dont care about it.)

conclution:
This works well.

[secile]

This is my working note.

as to No.1,
This didn't go very well.
The biggest problem is, I do not know how to create/update WriteableBitmap in another thread.
If I create WriteableBitmap in non UI thread, exception happen.

for my reference:
https://stackoverflow.com/questions/9868929/how-to-edit-a-writablebitmap-backbuffer-in-non-ui-thread

[secile]

@yangjieshao

It took a lot of time, but I released fix that do not allocate memory every time.
In result of that, less GC. please see picture in my last post.
Yom may expect less GC level same with SetPreviewControl,
there are some difficulties. It may not be possible.

The biggest problem is, it is not able to create WriteableBitmap instancde in Non UI thread.
WritetableBitmap must be created in UI thread, and before/after draw it, I have to lock/unlock properly.

[secile]

This is my working note.
I finally find a good solution and will release in a few days.

[secile]

@yangjieshao

I released fix of this issue.
10c6ca4

[yangjieshao]

首先，抱歉，我现在刚想到一个注意事项，
(First of all, I'm sorry, I just thought of a note)
在某些旧型号电脑上
(On some older computers)
特别是一些使用集成显卡的十几年前的电脑
(Especially some computers that used integrated graphics cards more than ten years ago)
WriteableBitmap 似乎无法渲染画面
(WriteableBitmap seems unable to render the picture)
有可能是显卡驱动的原因使得个别非常古老的电脑对WriteableBitmap支持似乎并不是很好
(It may be due to the graphics card driver that some very old computers do not seem to support WriteableBitmap very well)
所以需要保留每帧获取新的bitmap给到UI的可能
(So we need to keep the possibility of getting a new bitmap to the UI every frame)
非常抱歉我并没有查看您的代码是否有相关的考虑
(I'm sorry I didn't check your code )
我只是正好想到了这个问题
(I just happened to think of this note)

@secile