草拟这个问题的背景:在工作中我们使用Dell Precision工作站.我现在有一台NVidia Quadro FX1700.我的团队正在为实时数据采集系统开发图形组件.因此,我们一直在关注图形操作是否不会占用过多的CPU时间.为了快速检查,我们运行了几个测试程序,它们以指定的速率(例如10 fps)绘制场景,我们使用普通的旧任务管理器来查看CPU使用率的位置.其中一个程序很重视GDI DrawRectangle调用(已填充).这个程序总是占用大约40%的CPU用户时间,但是大约一年左右(这里只是猜测)它只使用大约2-3%的内核时间.很明显,这里正在进行一些硬件加速.事实上,如果我关闭HW-accell,我们' 重新回到原来的40%用户时间.所有这些当然都是好消息,因为我们已经在考虑转向OpenGL了.年复一年,GDI从未获得硬件加速的好处.直到前一段时间.
有谁知道更多关于这个？微软这样做了吗？或者是gfx-card供应商具体？
编辑
Thnx已经答案了(Ferrucio,Torlack和Rob Walker),但我的问题还没有得到解答.我们在这里谈论一个填充的矩形.可能是最优秀的功能:只需将几个坐标发送到GPU并让它翻录.但它总是在CPU端实现.到目前为止,答案让我相信NVidia终于看到了光明(超过10年后)并加速了GDI.没有关于此的公告？根本没有信息可以找到.我的内部客户问我关于图形加速的问题,我只能说"好吧,我们很幸运".
EDIT2
根据不同的答案,它似乎与驱动程序相关.因此,NVidia多年来为其工作站卡制作了糟糕的GDI驱动程序.在这家公司中,GDI没有被加速并且所有测试证实了这一点,这确实是一个公认的事实.
系统描述
使用OOXML生成文档的绘图组件.
绘图组件由几个部分组成.除了OOXML文档的接口之外,所有部分都用C++编写为exe + dll.后一个组件是在C#/ .NET中创建的COM组件.主要原因是.NET框架包含System.IO.Packaging.这是一个非常方便的内置工具,用于处理OOXML文档.
我们使用模板OOXML文档创建文档,其中某些零碎的部分由其实际内容替换.
其中一个位是OLE服务器组件.基本上这是OOXML文件中的二进制段.为了编写这个二进制段,Packaging组件显然使用了独立存储.
问题
写一个> 8MB的段导致抛出异常"无法确定域的身份".
在C++端,此异常包含错误ISS_E_ISOSTORE(0x80131450).
我们已经对此进行了分析,据我们所知,这是一个安全功能,可防止半不受信任的第三方组件通过编写大量文件来完全破坏您的HD.
然后我们在.NET/COM组件中尝试了很多东西(创建自定义AppDomain,设置属性以获得最大允许性,创建我们自己的Streams并将它们传递给Packaging组件)但每次都会导致抛出相同的异常.
我们可以做些什么来完成这项工作？
可能是当.NET组件被实例化为COM组件时,其AppDomain总是不受信任的？