我只是想知道GDI +是否仍然是值得使用的技术，尤其是在.net方面。

诚然，GDI +仍然是在Windows中处理图像的技术，但是(显然)它也是非托管代码。现在，在发现ASP.net1实际上不支持GDI +之后，我只是想知道：让图像处理库完全在托管代码中运行是否切实可行？如果我没记错的话，XNA会这样做，尽管它使用了图形卡。

甚至可能没有任何实现某种托管GDI +的.net图像库？

1 Source，微软也为使用GDI +的ASP.net提供了一些东西。

解决方案

回答

System.Drawing构建在GDI +之上。这只是一个包装。

http://msdn.microsoft.com/zh-CN/library/system.drawing.aspx

回答

它仍然是值得使用的技术。周围有许多使用GDI +的Windows窗体和非托管应用程序，它们或者不会升级，或者会升级，但不需要更高级的渲染功能。对于旧的应用程序和Windows Forsm编写的新应用程序，GDI +是一个很好的添加解决方案。这是在Vista中不放弃GDI +的主要原因，而希望使用完全DirectX解决方案。

GDI / GDI +没有特别的问题。没错，它不如Aero等人先进，但这并不总是很重要。特别是在LOB应用程序中(在甚至可能没有能够运行Vista我的机器的公司中也确实没有)，GDI +是一项极其重要的技术。

在ASP.NET中不支持(至少用于绘图的...我们仍然可以将其用于图像处理)的事实是一个麻烦，因为Web应用程序(基于插件的"应用程序"也不支持其他绘图技术) ")。

回答

可以用吗嗯，是。在一定程度上。它总是非常缓慢，文本渲染一直被破坏，并且很明显一段时间以来，它不再是Windows的"下一个官方图形层"。

如果我们不能忍受，那么还有很多其他图形库，更快和/或者更高质量，更少的系统依赖性...尽管我不知道在托管代码中有任何实现。

回答

Blockquote
  there are plenty of other graphics libraries out there, faster and/or higher quality / fewer system dependencies...

我们能否列出其中一些可以代替C ++使用GDI +的库？

回答

我们可以使用AntiGrain代替GDI +。有关使用此库的应用程序的示例，请参见Creative Docs .NET。

SDL也非常适合某些类型的应用程序。