本帖最后由 Loaden 于 2010-01-03 13:05:24 编辑

解决方案 »

  1.   

    Direct2D与DirectWrite更底层一些。
      

  2.   

    放弃gdi画图?开什么玩笑,那Windows里面无数代码、无数显卡驱动和第三方软件都需要重写。。
      

  3.   

    D2D和DWrite应该是和D3D一个层次的东西,和GDI一样,Flash比它高层多了。至于CPU占用高,因为Flash画出来的东西都是反走样的,这两个的差距对比一下GDI和GDI+的速度应该就能了解了。
    D2D流行的时候,Flash底层用这个重写一下就用得上硬件能力了。
      

  4.   

    看到一个msdn杂志上讲d2d的帖子 好像说vista下这玩意才好使
      

  5.   

    在D2D、DWrite出来之前,在D3D或者DDRAW上绘制文本一直是性能瓶颈,因为文字输出都依赖GDI库实现,无法硬件加速,游戏厂商通常使用预先提取字模的方式把有限的文字制作成图片,这样可以避开直接绘制文字。有些需要动态文字的游戏会为输出文字的区域单独创建一个精灵表面,在系统内存执行一些慢速文字处理,然后整体转换成图片纹理后才送入3D流水线。早期的D3D处理文字一直被诟病,直到D2D、DWrite出现。微软完全改写了底层,在文字处理上实现了硬件加速,不再依赖GDI和DC。说实话,我很想学到这两样技术,使之能被WIN7之前的操作系统使用。关于FLASH,我做过一些简单的对比测试,它并不是只用CPU实现,而是使用了DDraw技术,再加上ADOBE在图像处理算法方面有其自身优势,作出来的效果还是很好的,一般人无法超越它。但只要FLASH中使用了动态文字,无论FLASH是不是内置字库,速度都会降下来,没办法,GDI是避不过的槛。
      

  6.   

    是在网上看到的一个文章:Windows 7 前景不容乐观 - Ms抛弃GDI带来的沉痛代价
      

  7.   

    谢谢!长见识了!!
    看来以后使用Flash时,如果有性能要求时,应该避免使用动态文本。
      

  8.   

    DDraw本身在加速方面没什么优势,基本上就相当于早期的直接写屏技术。在绘制复杂一点的图形时(简单一点就加个反走样),瓶颈完全不在写屏速度上,画东西还是要靠CPU搞,否则也就不会用D3D来做2D图形了。
      

  9.   

    实际上GDI里一样可以用到硬件的能力,比如说那个BitBlt,就看厂家的驱动了。
      

  10.   


    为什么我用Win7下的DW没遇到文章里面说的那种很缓慢的问题?是不是他自己的显卡驱动兼容性不好呀
      

  11.   

    原文链接 : 2D Drawing APIs in Windows背景知识 : Windows 图形编程    在 Windows 7 操作系统中,微软花费了很大的力气构建了一套新的 2D 绘图 API。我们称之为 Direct2D ,隶属于 DirectX 家族。这个 API 的开发填补了 Windows 图形平台的一些缺陷。其中非常重要的一点就是普通的 2D 程序渲染不再缺乏硬件加速。而在 Windows Vista 中,我们知道 GDI 是无法进行硬件加速的。微软寄望于开发的这个 API 具备很多现代特性。比如支持抗锯齿和 Alpha Blend 的 2D 渲染,和其它现代图形 API 交互,服务器端渲染,诸如此类。    为了方便理解微软为何开发 Direct2D ,我们先来回顾一下当初开发 Windows 时的历史。最初的渲染系统叫做 GDI (图形设备接口),今天仍然存在。它最初为 16 位 Windows 写就,随后升级到 32 位 Windows (Windows 95 和 Windows NT)。因为 GDI 是为很久以前那些计算能力低下的计算机而开发的,所以它并没有诸如抗锯齿之类的特性,大多数 API 亦不支持 Alpha 通道。    在 Windows 95 期间,DirectX 发布了第一版。DirectDraw 是其中最早的组件之一。当初的本意是在硬件加速启用的情况下,开发人员可以绕过 WinG 允许,直接访问硬件。这样的一个协议堆栈既可以和 GDI 协作,但是又真正处在同一地位。    随着图形硬件(显卡)演进,GDI 通过 DDI (设备驱动接口) 获得了硬件加速的能力。很多视频卡实现了这些 DDI ,而通过购买一块视频卡来改善你的 Windows 性能亦成为平常之事。接下来,Direct3D 进驻到 DirectX 2 中,当然它也创建了自己的 DDI 集。随之,视频卡开始投入越来越多的精力来使得 3D 图形越来越快,以便维持游戏市场巨大的需求。最后导致诞生了两个不同的领域 : 硬件加速和图形编程。前者围绕于 Direct3D 构建,后者则围绕于 GDI 。    Direct3D 和 GDI 构建于不同目标,不同位置的事实意味着它们并不能像人们期望的那样能够良好的工作在一起。虽然实现了不少像 GetDC 这样的帮助桥接特性,但是在大量交叉渲染的场景下它们总是存在着或这或那的一些问题。尽管如此,微软并没有移除这些待解决的场景需求。    到了世纪之交,GDI 的限制越来越显现。微软针对这些功能缺陷做了一个 GDI 扩展,即 GDI+ 。这些扩展提供了诸如位图操作,画笔,抗锯齿和越来越复杂的 Primitive 渲染中不同像素深度格式,Alpha Blend 的支持。同时,GDI+ 亦包括了诸如打开 Png 和 Jpg 格式文件的图像操作支持。然而,GDI+ 新增的全部操作都没有硬件加速支持。    GDI+ 在托管世界中非常流行,这主要得力于它是 System.Windows.Drawing 命名空间的主力。每一个客户自定义渲染的非常漂亮的 Windows Form 程序都使用 GDI+ 来当此大任。但是,构建于 GDI 之上的 GDI+ 同样继承了与 Direct3D 交互的所有问题。事实上,因为它总是软渲染,在某些场景下,它会变得更糟。    当时间走到计划研发 Windows 7 时,很明显,微软需要解决很多互操作性的不足,以及不平衡的硬件加速能力。保留现有的 API 且要达到上述目的是相当困难的事情。GDI 有很长的历史,这需要应付海量的应用程序兼容性问题。如果要把 Alpha Blend 支持(举例) 弄进 GDI 核心 API 集合,而且还不得罪现有的客户无异于天方夜谭。因为 GDI+ 构建于 GDI 之上,旧有的陋习同样让它获得硬件加速能力变得难以实现。    解决方案就是创建新的 API 来囊括我们想要的功能和处理互操作性问题。MIL 代码(WPF 处理渲染的原生组件)是一个很方便的起点。它有着我们想要的渲染特性,而且同时提供了软件渲染和硬件加速。    首先需要做的事情是使渲染代码基于 D3D 10.1 ,而不是 D3D 9 。之所以这样决定是因为有一些构建于这个运行时版本的其它技术把 D3D 10.1 作为基础(10Level9,WARP,D3D Primitive Remoting)。而且我们还可以看到未来的硬件同样构建于这个架构之上。这样就能允许我们来设计 D3D 10.1 互操作性。因此就能允许与其它技术交互,比如 Direct2D 。    另外一个互操作性工作就是利用窗口管理器和 DXGI ,以确保 Direct2D 和 GDI 能够共同工作。你可以使用 Direct2D 绘图到 GDI 目标,同理,反之亦可。 但是,从性能的角度来看,这些特性并非免费。它只是让那些构建在这两种混合 API 上的应用程序能够平滑过渡到新世界。    前面所作的工作中很重要的一块就是尽量使得此 API 在性能方面富于表现力。对于开发人员来说,WPF 的好处在于它做了很重要的资源管理工作,但却使得直接控制硬件变得困难起来。这听起来貌似很简单,但是这背后有着大量的设计决定以确保 GPU 内存没有分配给不需要之人,且仍然能够允许人们构造他们之所想。因此遵循了这样一个原则的 Direct2D 设计和资源/线程模型就能够允许服务器端渲染进行合适的伸缩。GDI 却不能。    此外,对于处理文本和图像可以分别采用 DirectWrite 和 WIC 。这表明了微软 DirectX 家族正更加组件化。Direct2D 以一种互补的方式对 DirectWrite 文本和 WIC 位图操作提供硬件加速支持。    最后想说的是,我们构建了一个支持硬件加速的 2D 渲染 API (带有软渲染)。它有着现代渲染原语集合,能和以前的 API 进行交互。我们认为它完全可以取代作为大多数应用程序开发场景所使用的 GDI/GDI+ API ,而且也可以作为某些游戏开发场景中 D3D 10.1 的补充。微软构建的这么一套组件化的技术集合完全允许开发人员混合搭配以构造以前难以构造的事物。比如把已定位的文本像素直接渲染到 Direct3D 纹理当中,而不需要任何字体的支持。
      

  12.   

    http://technet.microsoft.com/zh-cn/library/ee921514.aspx
      

  13.   

    GDI有着自身无法逾越的障碍,所以Direct2D才被推出,同时GDI亦实现了硬件加速,只效果不如Direct2D,
    我想微软有意鼓励大家在以后的程序中使用Direct2D吧,
    不久以后,窗口绘制底层亦将由Direct2D来实现
      

  14.   

    现在底层早已经是DXGI和D3D在工作了,从Vista开始GDI已经被架空到应用层,GDI也从内核中被踢出来了
      

  15.   

    照这样下去,估计发展到最后所有图形编程干脆全都移植到GPU去得了,
    CPU已经日益没什么太大的作用了,计算能力现在也似乎并不被人们所关注,人们越来越关注的是显卡,显存之类的而图形开发程序员也很依赖于Shader之类的
      

  16.   

    不用争论,其实现在GDI在windows下都是一个代理,真正工作的还是DirectX, 如果想深入了解win7& vista框架,请参考http://technet.microsoft.com/zh-cn/library/ee921514.aspx
      

  17.   

    其实GDI是硬件加速的,这个在Windows 3.x时代的所谓图形加速卡,就已经开始加速了。Win32时代更是基本都加速的。
    但是 GDI+ 就没有硬件加速了。
    我个人是愿意编写Windows XP For GDI/GDI+,Windows 7 For Direct2D/DirectWrite的程序的,目前也是按此运作的
      

  18.   

    怎么就没人谈谈 Direct2d 与DirectDraw 的关系了?