MFC中的硬件加速

Question

我目前正在开发一个软件，涉及实时绘制图形和图表形式的性能指标。我需要获取数据，处理数据，并尽快渲染图像。我的后端是在C++中的，我正处在一个必须对前端做出选择的时刻。考虑到我的后端在C++中，我倾向于使用MFC。另一种选择是使用WPF C#作为前端，并与我的C++后端进行互操作。我最近读到WPF提供硬件加速，这将帮助我实现高帧速率。MFC硬件也能加速其图形化吗？硬件加速甚至重要吗？考虑到WPF的硬件加速，在我的例子中，这是否使WPF成为图形最有效的替代方案？

Answer 1

WPF使用DirectX 9提供硬件加速，我相信。然而，对于线条图来说，限制因素是界面元素的数量。我们正在创建一个使用Telerik图表实时显示sEMG数据的WPF程序.这些可以配置为在引擎盖下使用direct2d加速，如果有大量的数据点，这会稍微提高性能。但是，它仍然不稳定，因为您无法控制WPF的呈现线程。

这在某种程度上取决于您在图形中需要的功能数量。如果优先是有丝光滑的实时显示，不要与WPF。

Answer 2

Visual 2010向MFC添加了类，以支持使用来自MFC程序的Direct2D呈现。

要使用Direct2D，首先在视图的OnCreate中调用EnableD2DSupport() (从技术上讲，我认为它不一定在OnCreate中，但这是通常的位置)。然后，当AFX_WM_DRAW2D显示上下文需要更新时，您将收到D2D消息，因此您通常希望为此添加一个处理程序，并通过根据需要呈现内容来响应它。

另一个需要考虑的可能性是使用现有的控件来绘制图形。有相当多的，包括一些是免费的相当宽松的许可。例如，CodeProject有许多图表控制，其中一些使用D2D进行绘图，还有更多的没有使用D2D。

老实说，我会有点惊讶的是，图表的信息更新的足够快，绘制速度，以产生巨大的变化，但作为一项规则。在大多数典型情况下，真正的限制将是用户理解所绘制的内容的能力。一个用户根本无法观看100种不同的图形，每个图在60赫兹时被更新，并且很有希望从其中的大多数图中得到更多的真实意义。在大多数情况下，真正的挑战不是更快地吸引更多的数据，而是为用户提供更好的方法来集中精力于他们一次可以关注的少数事情，并且(例如)在需要时提请他们注意重要的更改。