IIS&基于服务的Web图像生成-GDI，GDI +或Direct2D? [英] IIS & service-based generation of web images - GDI, GDI+ or Direct2D?
问题描述
现在是2017年5月.我的老板要求我根据用户在浏览器中输入的文字来生成一些代码，以在我们的网站上制作一些自定义的网络图像.
服务器环境是运行IIS的Windows 2012，我对C#熟悉.从我的阅读中，我应该能够使用GDI +来创建图像，在其中绘制流畅的文本等.
但是，我的一位同事建议GDI +可能无法在Windows Server上运行，并且该GDI +基于较旧的32位GDI，因此将在一天之内被废弃，因此我应该改用DirectX.我认为，引入另一层将使编写和处理问题变得更加复杂.支持.
有很多网页讨论这些主题以及每个主题的性能，但是感觉并没有定论，因此我要求SO社区提供经验.
所以，问题是:GDI是否可以在Windows Server上使用?
感谢您的答复.从他们那里我看到我在几点上有点含糊.具体来说，我们打算将图像渲染过程设为基于队列的过程，并使用运行GDI +图形代码的服务.我刚刚阅读了这是从2013年开始的，这表明GDI +不应在服务中运行，并建议Direct2D是MS首选的处理方式.
进一步的研究发现 sharpdx 作为MS DirectWrite的包装库，后者本身就是Direct3D API系列的一部分.我们不是100％肯定会要求使用Sharpdx，并且在继续寻找额外层所代表的好处或阻碍时，我们将把它与单独的DirectWrite实现进行比较.我们相信，在这一点上，这将遵循MS在上面的示例中试图建议的方向，并且我们将摆脱服务环境中的GDI/+缺陷，并能够受益于DirectWrite的性能和功能提升.我们将会看到.
深入研究SharpDx之后，我们正在取得进展，Mgetz提到的有关"WARP"的内容现在很有意义. Direct3D是我们通过SharpDX API访问的基础技术.与所有低级图形工作一样，我们请求设备上下文(又称为dc)，然后请求绘图表面，然后进行绘制.设备上下文部分是 WARP所在的位置进来.DC通常位于硬件设备的前面-但在我的项目中，我的目标是服务器上的服务，因为服务器上不太可能会有图形处理器，甚至可能没有视频卡.如果是虚拟服务器，则视频处理器可以共享等.因此，我不想绑定到物理"硬件设备.输入WARP(查看的好时间完整上下文的链接)，这是dc的完全软件实现-没有硬件依赖性.甜的.以下是链接页面的摘录:
在Direct3D 10硬件不可用时启用渲染
WARP允许在各种硬件情况下快速渲染 实现不可用，包括:
当用户没有任何具有Direct3D功能的硬件时，当应用程序作为服务运行或在服务器环境中运行时
未安装视频卡时
当视频驱动程序不可用或无法正常工作时
当视频卡的内存不足，挂起或需要过多的系统资源来初始化
在您的情况下，我可能会尝试使用SkiaSharp(this from 2013 which suggests that GDI+ should not be run within a service, and suggesting that Direct2D is the MS preferred way-to-go.
EDIT 2: Further research has found this page. It says the options are GDI, GDI+ or Direct2D. I copy the key paras here, though the entire page is a quick read so view at source for context if you can.
Options for Available APIs
There are three options for server-side rendering: GDI, GDI+ and Direct2D. Like GDI and GDI+, Direct2D is a native 2D rendering API that gives applications more control over the use of graphics devices. In addition, Direct2D uniquely supports a single-threaded and a multithreaded factory. The following sections compare each API in terms of drawing qualities and multithreaded server-side rendering.
GDI
Unlike Direct2D and GDI+, GDI does not support high-quality drawing features. For instance, GDI does not support antialiasing for creating smooth lines and has only limited support for transparency. Based on the graphics performance test results on Windows 7 and Windows Server 2008 R2, Direct2D scales more efficiently than GDI, despite the redesign of locks in GDI. For more information about these test results, see Engineering Windows 7 Graphics Performance. In addition, applications using GDI are limited to 10240 GDI handles per process and 65536 GDI handles per session. The reason is that internally Windows uses a 16-bit WORD to store the index of handles for each session.
GDI+*
While GDI+ supports antialiasing and alpha blending for high-quality drawing, the main problem with GDI+ for server-scenarios is that it does not support running in Session 0. Since Session 0 only supports non-interactive functionality, functions that directly or indirectly interact with display devices will therefore receive errors. Specific examples of functions include not only those dealing with display devices, but also those indirectly dealing with device drivers. Similar to GDI, GDI+ is limited by its locking mechanism. The locking mechanisms in GDI+ are the same in Windows 7 and Windows Server 2008 R2 as in previous versions.
Direct2D
Direct2D is a hardware-accelerated, immediate-mode, 2-D graphics API that provides high performance and high-quality rendering. It offers a single-threaded and a multithreaded factory and the linear scaling of course-grained software rendering. To do this, Direct2D defines a root factory interface. As a rule, an object created on a factory can only be used with other objects created from the same factory. The caller can request either a single-threaded or a multithreaded factory when it is created. If a single-threaded factory is requested, then no locking of threads is performed. If the caller requests a multithreaded factory, then, a factory-wide thread lock is acquired whenever a call is made into Direct2D. In addition, the locking of threads in Direct2D is more granular than in GDI and GDI+, so that the increase of the number of threads has minimal impact on the performance.
After some discussion of threading and some sample code, it concludes...
Conclusion
As seen from the above, using Direct2D for server-side rendering is simple and straightforward. In addition, it provides high quality and highly parallelizable rendering that can run in low-privilege environments of the server.
Whilst I interpret the slant of the piece as being pro-Direct2D, the points on locking and session-0 for GDI+ are concerning. Arguably, since we propose a queue-based process, the locking issue is less severe, but if there are immediate and practical restrictions to what a service can do with GDI+ then it looks like Direct2D is the only viable route for my project.
Did I interpret this correctly or has the SO community more recent & relevant experience?
EDIT: With the initial batch of responses slowing up and no sign of a definitive answer, I add this edit. The team here has selected sharpdx as a wrapping library to MS DirectWrite which is itself part of the Direct3D family of API's. We are not 100% certain that sharpdx will be required and we will be comparing it to a solely DirectWrite implementation as we go along looking out for the benefit or hindrance the extra layer represents. We believe at this point in time that this follows the direction MS were trying to suggest in the article sampled above, and that we will be free of GDI/+ shortcomings in a service environment and able to benefit from performance and feature gains in DirectWrite. We shall see.
EDIT: Having delved into SharpDx we are making progress and something mentioned by Mgetz about 'WARP' now makes sense. Direct3D is the underpinning tech we access via the SharpDX API. AS with all low-level graphics work, we request a device context (aka dc), then a drawing surface, then we draw. The device context part is where WARP comes in. A dc is usually fronting a hardware device - but in my project I am targeting a service on a server where it is unlikely that there will be a graphics processor, and maybe not even a video card. If it is a virtual server then the video processor may be shared etc. So I don't want to be tied to a 'physical' hardware device. Enter WARP (good time to view the link for full context), which is an entirely software realisation of a dc - no hardware dependency. Sweet. Here is an extract from the linked page:
Enabling Rendering When Direct3D 10 Hardware is Not Available
WARP allows fast rendering in a variety of situations where hardware implementations are unavailable, including:
When the user does not have any Direct3D-capable hardware When an application runs as a service or in a server environment
When a video card is not installed
When a video driver is not available, or is not working correctly
When a video card is out of memory, hangs, or would take too many system resources to initialize
In your case, I would probably try to go with SkiaSharp (https://github.com/mono/SkiaSharp) to abstract a bit from the platform/API details
这篇关于IIS&基于服务的Web图像生成-GDI，GDI +或Direct2D?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
