我使用 MFC 开发了一个相当大的应用程序。自然，我使用 GDI 进行绘图，使用 CCmdTarget 进行事件路由，以及文档视图架构。这是一条便捷的发展道路。
现在，客户有兴趣将此应用程序转换为 .Net。我更喜欢（他们也喜欢）用 C# 编写新产品。
该应用程序显示数千个图形对象并与之交互，所以我认为使用 GDI+，虽然看起来很自然，但会导致性能问题，所以我正在考虑使用 OpenGL，特别是 OpenTK - 作为图形库（它是 2D）。
我知道 OpenGL 的工作方式与这些依赖于屏幕部分失效的 Windows API 不同。OpenGL 有一个不断绘制到屏幕的渲染循环。
我的问题是：这是一种可以接受的方式吗？
性能——用户是否需要特殊的显卡（硬件？）。它是图形密集型游戏，但不是高端游戏
打印和打印预览——这些事情实现起来很复杂吗？
多选和上下文菜单
这个库在 Windows 窗体中运行良好吗？
我不这么认为。如果可以，请使用 WPF，如果不能，请使用 DirectX。
我知道这可能不公平，但如果我在 windows (microsoft) 上的 .NET (microsoft) 上编程，我宁愿使用 DirectX ...它也来自 microsoft。
作为旁注：不要重新发明轮子。在 open-gl 中重新编码用户控件可能会非常耗时，如果你确定你有充分的理由。
根据我开发类 CAD 软件的经验，OpenGL 和 DirectX 的好处是快速深度测试、平滑旋转和平移、照明和强大的纹理功能。显然还有其他好处，但尽管大多数教程会让您相信，使用这些 API 中的任何一个来实现渲染系统都是一项重大任务，不应掉以轻心。
具体来说：
如果它是一个 2D 应用程序并且您已经在 GDI 中实现了它，那么切换到 GDI+ 会容易得多。此外，在现代硬件上，2D GDI 或 GDI+ 可以与 2D OpenGL 或 DirectX 一样快。最终，最终用户可能不会注意到差异，尤其是 GDI+ 中的双缓冲支持。
您不需要（也可能不希望）您的应用程序的连续渲染循环。在 OpenGL 和 DirectX 中，您可以在场景更改时显式地使窗口无效。
如果您使用 OpenGL 或 DirectX，您将需要考虑将您的对象放入显示列表或顶点数组（缓冲区）中以进行快速绘图。这并不难，但以这种方式管理对象会增加系统的复杂性，并且很可能会显着改变渲染系统的架构。
在 OpenGL 或 DirectX 中打印也可能很乏味。一方面，您可以渲染位图并将其打印出来。但是，对于高质量的图像，您可能需要矢量化图像，这很难使用这些渲染框架中的任何一个生成。
我也不会在 OpenGL 或 DirectX 中编写 GUI……除非你真的在寻找挑战 ;~)
最后，从安装的角度来看，这只是一个烦恼，必须安装在用户机器上的托管 DirectX 运行时库大约为 100 MB。
我没有使用 C# 的经验，但是我曾经为使用 openGL 进行渲染的绘图程序构建了一个图层系统。
为了制作这一层，我向 openGL 询问了当前帧缓冲区并将其转换为图像以用作当前画布下的纹理。所以我想从那里很容易去打印和打印预览。
Direct X 和 Open GL 比 GDI+ 快得多。
您还可以使用TAO 框架作为 OpenTK 的替代方案。