c# - 在 WPF 中一次快速绘制大量矩形

Question

我的应用程序接收来自外部设备的数据。每个数据点后，有一个短的电子死区时间(大约 10µs)，其中没有其他数据点可以到达，我的应用程序应该使用它来处理和显示散点图中屏幕上的数据。我最重要的目标是不超过这个电子死区时间。如何在基于 WPF 的应用程序中解决这个问题，以及对不同方法进行基准测试的方法是什么？

我尝试过的是:

• 在 Canvas 中为每个到达的数据点创建一个 Rectangle。这太慢了 10 倍。
• 相同的方法，但在自定义控件中绘制 DrawingVisuals。好多了，但还是有点太慢了。向树中添加视觉/逻辑子项可能会产生过多的开销。
• 一个 UserControl，其中所有数据点都存储在一个数组中并显示在 OnRender 方法中。在这里，我必须在每次调用 OnRender 时再次绘制每个点。因此，这种方法会随着时间的推移而变慢，这是不希望的。有没有办法告诉 OnRender 不要在每次传递时清除屏幕，以便我可以逐步绘制？
• 将每个点显示为 WriteableBitmap 中的一个像素。这似乎可行，但我还没有找到一种方法来确定使位图的一部分无效是否偶尔会增加一些非常长的等待时间(当图像实际上在屏幕上刷新时)。有什么衡量方法吗？

编辑:

在评论中，缓冲数据并以较慢的速率显示数据的观点已经提出。这种方法的问题是，在某些时候我必须处理缓冲区。在测量期间这样做会引入很长一段时间，在此期间我的系统很忙并且新事件将被丢弃。因此，单独处理每一点，但为了好的，会更可取。使用 10 µs 触发每个事件的显示比立即将其存储到缓冲区并每 50 ms 左右使用 100µs 来处理累积事件要好得多。

在过去(即非 WPF)时代，您可以把需要的数据放到显存里，让显卡在方便的时候处理。当然，它实际上不会以快于 60Hz 的速率显示，但您不必再次触摸此数据。

Answer 1

使用 WriteableBitmap将是最快的方法。为了进行测试，您可以预先分配一个数组并使用秒表在进行渲染时对计时进行采样，然后您可以分析计时以了解性能。

您遇到的一个首要问题是垃圾回收。不幸的是，这将引入您描述的确切类型的性能问题的可能性，即在执行 GC 时偶尔停顿。您可以尝试使用低延迟 GC 来缓解这种情况。

更新

这是一个使用低延迟 GC 的示例:

http://blogs.microsoft.co.il/blogs/sasha/archive/2008/08/10/low-latency-gc-in-net-3-5.aspx

您可以利用它来确保在“死时间”(即渲染时间)期间没有垃圾回收。

更新 2

正如我刚才在评论中提到的 - 您是否正在对 WritableBitmap 进行批处理更新？

您的设备更新频率太高，无法维持每次设备更新都写入位图 - 我认为每秒有 10k-100k 次更新。尝试以更合理的频率(例如每秒 60 或 25 次)更新位图，因为强制位图渲染的开销将以每秒 10k-100k 的更新速度支配性能。当您收到设备更新时写入缓冲区，然后定期将此缓冲区传输到 WritableBitmap。您可以为此使用计时器，或者每 n 次设备更新一次。通过这种方式，您将批量更新并大大减少 WritableBitmap 渲染开销。

更新 3

好吧，听起来你每秒更新 WritableBitmap 10k-100k 次——这是不可行的。请尝试前面所述的基于帧\批处理的机制。此外，您的显示仅可能以每秒 60 帧的速度更新。

如果您担心阻止设备更新，请考虑使用两个交替的后台缓冲区和多线程。通过这种方式，您可以定期切换设备写入哪个后台缓冲区，并使用第二个线程将交换的缓冲区渲染到 WritableBitmap。只要您可以在 < 10µs 内交换缓冲区，您就可以在死区时间内执行此操作，而不会阻止您的设备更新。

更新 4

进一步回答我的问题，似乎当前每秒 100k 更新中的每一个都调用了“锁定\解锁”。这可能会破坏性能。在我的(高性能)系统上，我在大约 275 毫秒时测得 100k“锁定\解锁”。这非常重，在功率较低的系统上会更糟。

这就是为什么我认为每秒 10 万次更新是无法实现的，即锁定 -> 更新 -> 解锁。锁定太昂贵了。

您需要找到一种方法来降低锁定调用的数量，方法是完全不锁定、每 n 个操作锁定一次，或者可能批处理请求，然后在锁定中应用批处理更新。这里有几个选项。

如果您进行批量更新，它可以小至 10 个周期，这将使您的更新频率降至每秒 10k 次更新。这会将您的锁定开销减少 10 倍。

用于锁定 100k 调用开销的示例基准代码:

lock/unlock - Interval:1 - :289.47ms
lock/unlock - Interval:1 - :287.43ms
lock/unlock - Interval:1 - :288.74ms
lock/unlock - Interval:1 - :286.48ms
lock/unlock - Interval:1 - :286.36ms
lock/unlock - Interval:10 - :29.12ms
lock/unlock - Interval:10 - :29.01ms
lock/unlock - Interval:10 - :28.80ms
lock/unlock - Interval:10 - :29.35ms
lock/unlock - Interval:10 - :29.00ms

代码:

public void MeasureLockUnlockOverhead()
{
    const int TestIterations = 5;

    Action<string, Func<double>> test = (name, action) =>
    {
        for (int i = 0; i < TestIterations; i++)
        {
            Console.WriteLine("{0}:{1:F2}ms", name, action());
        }
    };

    Action<int> lockUnlock = interval =>
    {
        WriteableBitmap bitmap =
           new WriteableBitmap(100, 100, 96d, 96d, PixelFormats.Bgr32, null);

        int counter = 0;

        Action t1 = () =>
        {
            if (++counter % interval == 0)
            {
                bitmap.Lock();
                bitmap.Unlock();
            }
        };

        string title = string.Format("lock/unlock - Interval:{0} -", interval);

        test(title, () => TimeTest(t1));
    };

    lockUnlock(1);
    lockUnlock(10);
}

[SuppressMessage("Microsoft.Reliability",
    "CA2001:AvoidCallingProblematicMethods", MessageId = "System.GC.Collect")]
private static double TimeTest(Action action)
{
    const int Iterations = 100 * 1000;

    Action gc = () =>
    {
        GC.Collect();
        GC.WaitForFullGCComplete();
    };

    Action empty = () => { };

    Stopwatch stopwatch1 = Stopwatch.StartNew();

    for (int j = 0; j < Iterations; j++)
    {
        empty();
    }

    double loopElapsed = stopwatch1.Elapsed.TotalMilliseconds;

    gc();

    action(); //JIT
    action(); //Optimize

    Stopwatch stopwatch2 = Stopwatch.StartNew();

    for (int j = 0; j < Iterations; j++)
    {
        action();
    }

    gc();

    double testElapsed = stopwatch2.Elapsed.TotalMilliseconds;

    return (testElapsed - loopElapsed);
}