快速库替换 CDC 矢量图形
我有一个成熟的 MFC C++ 应用程序，它在屏幕上显示并在 Win32 GDI 上使用 CDC 包装进行打印。 虽然它多年来一直在优化，但我想用更快的东西来替换它。 图形包括渲染的三角形表面模型、复杂的折线和多边形以及大量文本。 它需要满足以下标准；
显示的向量数量可能非常大。 例如，单个表面三角形在渲染时可能会生成数轴和实心填充。 目前，这些信息没有存储在任何地方，而是动态生成和绘制的。 SDK应该支持限制缓冲向量的总数，否则可能会耗尽内存。
SDK 应该能够渲染到任何 CWnd 派生类，包括 CView 和 ScrollView 类。
SDK 应支持打印到任何 Windows 打印设备，
SDK 应足够低级别，以便从低级别 CDC / GDI 调用进行端口相对简单。
开源总是好的，但是一次性成本高达 2000 美元，并且具有可选的升级/支持也可以。 每个用户的许可成本是不可接受的，
访问源代码将是一个很大的好处，特别是考虑到在 Windows CE / Mobile 上运行部分 SDK 的想法。
我目前正在处理自己的 3d 到 2d 视口管理。 如果没有像样的低级 SDK，则更高级别的 SDK 必须能够很好地处理 3D，并在 32 位 Windows 平台上处理数百万个三角形、多边形和文本实体。
有什么建议么？ 在您提出的建议中列出具体的优点和缺点将不胜感激。
I have a mature MFC C++ application that displays on screen and prints using CDC wrappings on the Win32 GDI. While it has been optimized over the years, I would like to replace it with something a bit faster. The graphics included rendered triangular surface models, complex polylines and polygons, and lots of text. It needs to meet the following criteria;
The number of vectors displayed is likely to be very large. For example a single surface triangle is likely to generate a number lines and solid fills when rendered. At present this information is not stored anywhere, it is generated and drawn on the fly. The SDK should support limit the total number of buffered vectors, or it is liable to run out of memory.
The SDK should be able to render to any CWnd derived class including CView and ScrollView classes.
The SDK should support printing to any Windows print device,
The SDK should be low level enough to make the port from low level CDC / GDI calls relatively straightforward.
Open source is always nice, but a one off cost of up to say $2k, with optional upgrades/support would also be ok. A license cost per user is not acceptable,
Access to source code would be a big bonus, specifically with the idea of running portions of the SDK on Windows CE / Mobile.
I currenly handle my own 3d to 2d viewport management. If a decent low level SDK is not available, a higher level SDK must handle 3d well, and work with millions of triangles, polygons and text entities on a 32 bit windows platform.
Any suggestions? Listing the specific pros and cons in your proposed suggestion would be greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为 DirectX 或 SDL 会满足您的需求。 它们专为 3D 设计，但也适用于 2D。 两者都支持 Windows CE / Mobile，并且 SDL 也可用于一堆非 Microsoft 操作系统。
不幸的是，库不支持与 GDI 的直接兼容。 但是您可以通过创建一个转换器类来实现这一点，该类将接受来自 GDI 设计的应用程序类的所有输出图形，并转换格式以满足 DirectX 或 SDL 类的需要（取决于您想要使用什么）。
我个人曾经做过一次这样的转换器类。 我有一个使用 SDL 为 Pocket PC 编写的游戏，我需要将其移植到 Palm 设备上。 在那里，我必须使用不同的图形库（我现在不记得该库的名称），但我成功地将所有 SDL 函数输出移植为其他库所需的格式。 我需要更改我的应用程序以调用转换器（包装器）函数，该函数将调用转发到 Palm 或 Pocket PC 库，具体取决于当前运行的设备。 所以我认为你可以做同样的事情来转换 GDI -> DirectX 或 GDI -> SDL。
I think DirectX or SDL will suit your needs. They are designed for 3D but work for 2D as well. Both support Windows CE / Mobile and SDL is also available for a bunch of non-Microsoft OS.
Unfortunately direct compatibility with GDI is not supported in the libraries. But you can do the trick by creating a converter class, which will accept all output graphics from your GDI designed application classes and convert the format to fit the needs of DirectX or SDL classes (depending what do you want to use).
Personally I made such converter class once. I had a game written for Pocket PC, using SDL and I needed to port it to Palm device. There I had to use different graphics library (I don't remember the name of the lib now) but I succeeded to port all SDL functions output to the format needed by the other lib. I needed to change my application to call the converter (wrapper) functions, which forwarder the call to Palm or Pocket PC library, depending on which device it is currently running. So I think you can do the same for converting GDI -> DirectX or GDI -> SDL.
我曾经评估过 FastGraph (http://www.fastgraph.com) 的一个项目。 我在我编写的小测试程序中喜欢它，它非常快。 由于外部原因我们最终没有使用它（与我评估的库无关），所以我没有更多的实践经验。
I have once evaluated FastGraph (http://www.fastgraph.com) for a project. I liked it in the small test programs I wrote, it was very fast. We ended up not using it for external reasons (nothing to do with the libraries that I evaluated) so I don't have more practical experience.