GDI+有人用吗？慢的一B

最多用来加载各种图像文件，然后拷出位图，自己处理。直接用graphic绘图，简直是变态，微软怎么想的。

解决方案 »

  1.   

    gdi+实际上是一个对gdi的封装，没有新东西。
      

  2.   

    除此之外，还有渐变画刷、Alpha通道合成运算、矩阵和矩阵变换等。
    　　
      

  3.   

    其实习惯也就好了
    有段时间想转型
    从GDI过渡到GDI+
    不过发现GDI+的文字绘制太麻烦了
    当然也有可能是我学艺不精
    所以到现在还是使用GDI
      

  4.   


    每当我看到这些谬论的时候，总有一种想骂人的冲动，不过骂人必然会导致别人骂我，不值得。CSDN有太多的菜鸟了，真是可惜了这个好论坛啊。GDI+的绘制确实比GDI慢了一个档次，有几个解决方案，一是用cachedbitmap,还有一个就是把图像加载为用PARGB格式的图像。可以参考这篇文章：http://www.codeproject.com/Tips/66909/Rendering-fast-with-GDIplus-What-to-do-and-what-no.aspx
    Rendering fast with GDI+ - What to do and what not to do!作为一个图像图形库，GDI+在很多方面不是GDI能比拟的。
      

  5.   

    在大多数应用情况下，如果你能判断的图像的格式是24位的话，就可以用GDI的函数直接输出图像到DC,如果是32位的图像，不是很好办，因为能正确显示32位图像的GDI函数只有一个：AlphaBlend，对这个函数有一定层次了解的就知道在显示32位图像前，还必须保证他是PARGB格式的，否则显示的效果也不对。GDI+要显示ARGB格式的32位图像，在内存也是存在一个类似于转换为PARGB格式的过程，有一个过程可以从大量的实际编码中得到，如果32位图像中alpha通道=255的像素数比较多的话，那么显示的速度比大部分像素alpha<>255的图像显示的药快，这也是因为这个预乘的存在。GDI+还有一个性能瓶颈，就是缩小图像时，不管你的目标图像多小，他都会从全图采样，这导致绘图过程缓慢，而写过图像缩放程序的人都知道，在缩小图像的过程中，所需要的循环是由小图像的大小决定的。如果楼主能力够强，最合适的办法是自己写缩放函数，直接计算混合到目标画布后的图像值。
      

  6.   


    这方面你应该是专家了
    呵呵
    其实我觉得闻道有先后，术业有专攻
    每个人都不可能面面俱到么
    GDI+有优势这是不言自明的
    不过也正如你所说的
    真正要做专业图形图像处理要么用专用SDK要么自己写底层
    无论是GDI还是GDI+我觉得它都不是面向专业图形开发的工具
    而一旦脱离专业领域
    对于一些外行人（比如说我）来说对他的评价自然会显得有失水准
    而只是从个人体验来评价
      

  7.   

    GDI+是一个2D图像库，是对GDI功能不足的补充，不存在可比性，比GDI慢也是正常的，任何其它同类的2D库都比GDI慢。
    但要说它慢得不可忍受，也是一种误解，它的特点是平台通用性和稳定性，比某些第三方2D库是慢些，但并不是一点优化也没有，至少我能看出它用多线程执行图像运算，不过是不是使用了多媒体指令或者GPU运算就不得而知了。
      

  8.   

    关于gdi的速度问题，实际上在单纯的图像显示上，gdi的绘图函数并不比dx和opengl慢，它们都是用硬件直接绘图，依赖于你的显卡。所谓的dx和opengl这些专业的绘图编程库，主要是集成了很多运算（效果），你要动态的显示一个3D物体，你自己编的话，是用cpu来运算。那些专业库有现成的函数处理，并且可能由显卡来完成，肯定快很多。它们的差别在这里。
      

  9.   

    关于laviewpbt的意见我有一下看法：我一贯不喜欢微软的集成的东西，mfc见了就头疼，大不说，你编完程序还要附带个1M多多dll，有那个学习成本，自己搞都能搞出来了，当然了，不可能什么都自己搞，这时候mfc是个很好的偷懒工具，但是，一方面mfc学习成本不低，另一方面，除非万不得已，还是别用它。现在之所以mfc编的程序不算少，完全是因为微软大力推广，硬培养出了一批mfc程序员。gdi+的情况是类似的，它集成了很多效果和高级函数。但是这些东西，一方面用的不多，真用的时候，发现又不能满足自己的要求。我用gdi和gdi+编写了一个绘图的库，注意很小，gdi+就是用来加载和保存bmp格式以外的图像文件。功能如下：加载保存机器支持的任何格式图像文件。
    任意绘制一个图像为任意大小，含alpha通道，也就是透明效果。
    任意切割和缩放一个图像。
    转换图像为任意位数。
    把图像的位图数据提取为数组，一般如果要处理数据32为是最方便的。
    把处理后的数据刷新到图像。
    转换bmp图像为图标，windows图标在内存里其实可以是任意大的。没有256像素的限制，但是图标文件格式不能超过这个限制。
    把图标转换为图像。
    。。你觉得还有那些功能必须用gdi+呢，我宁可自己写效果也不愿意使用现成的微软的那些复杂函数，他们的效果真的不尽如人意。
      

  10.   

    既然在讨论MFC的东西，那么就不要说MFC复杂，因为这是我们生存的工具我个人很不喜欢某某人说： xx技术垃圾，慢的要死、一堆问题……，因为这是一种不负责任的说法现在软件开发已经脱离了个人英雄年代，为了能更快更高效的实现我们的目的，就应该代码复用，不能全部东西都从零开写吧？前人的经验能够更快速的提升我们的开发效率，代价就是我们要去熟悉他，不去谦虚的学习而大言不惭的下结论说什么什么不好低效的人，不是一个好的开发人员虽然技术在进步，前辈的代码肯定存在很多不足，但是我觉得这种缺陷，平常的开发应用碰到的应该不多在遇到问题的时候，首先怀疑自己，其次再怀疑他人我也在用GDI+做界面，是比GDI慢，铁定的，但是真的说到慢到无法忍受，没见过，还是分析自己的原因吧
      

  11.   

    mfc我不喜欢，这是个人问题，但是不光我，连微软自己都不怎么用mfc，他们干嘛还搞atl，wtl呢？但是又不把它做成产品，不提供文档。不喜欢mfc的人很多，包括很多专家。我没有说gdi+慢到无法忍受，那种情况不多，但是如果能够更快，我绝不用慢的方法。其实真正的问题是，到底是自己开发快还是去研究gdi+和mfc的文档快。首先，mfc又慢又大，而且设计的很难说合理，当然，微软的东西，权威性还是有的，肯定很多人拥护。比如加载图像文件，这不是一个人能搞的，还有多媒体文件的格式，播放，转码，这是必须由别人提供功能的东西，好坏你都得用。但是说到绘图，没发现非用gdi+不可的地方。现在大多软件的界面，你觉得有多少是用微软提供的东西做的呢？
    微软的工具栏，按钮图像，ComboEx等很多控件，微软设计了很多功能，但是有多少人在用呢？稍微讲究一点的程序，都在自己做效果。RichEdit控件有多复杂，但是那个编辑器会用它呢？。doc文件有多复杂，有多少接口，标准，word可以用来看网络电视，但你会用它看吗？微软那些东西，换了任何一个公司都做不出来，因为太庞大，太复杂，其实，微软开发的东西，人们能用到10%就不错了。mfc也是一样，有个专家说过，mfc从来也没有流行过。
      

  12.   

    你用gdi+做一个简单的图像显示程序，然后拖动窗口，图像随窗口大小变化。你会看到强烈的闪烁，即使用了缓存dc，显示也是相当的慢，资源耗用非常高。直接用gdi的绘图函数画，基本没有闪烁，因为用不着刷新整个dc。微软设计这些东西就是给那些不讲究的人用的。
      

  13.   

    重写OnEraseBkgnd   
    再加上双缓冲可以解决闪烁问题，不要遇到问题了就归结为类库的问题，只是你自己不会用而已。
      

  14.   


    你看，你这么说问题就来了
    如果缓冲dc用的好，我不相信还会有闪烁
    无论是gdi还是gdi+,只是绘制技术，跟双缓冲无关
    还是先搞清楚到底是自己在什么地方产生了闪烁吧，不要出了问题不思解决，就一股脑的归结在技术上微软的技术一定也有很多缺陷，但是出了问题，更应该先考虑自身，而不是埋怨他人
      

  15.   

    专业图像处理，从来不用GDI+。
    做过的才知道为什么。
      

  16.   

    本来不想讨论下去了，就是看看大家对gdi+的态度。顶下楼上的。但是回答一下另外几位，你怎么知道我没用双缓冲，你怎么知道我没写OnEraseBkgnd，我一般为了不闪烁，背景会设成透明的。我最后一句，资源占用高的意思，就是不闪烁了，但是资源占用也上去了。
      

  17.   

    如果图片不是很大计算量不是很大,GDI+还是不错的.
      

  18.   

    有本书，《精通GDI+编程》LZ可以看看
      

  19.   

    不是GDI+慢，是你自己没用好！C#的WinForm就是用GDI+又不见人家说慢？
    想自己做这样又做那样的人结果是什么都做不成！不信你做个1/10的MFC出来？或者做个WTL出来？不知天高地厚！
      

  20.   

    无论在哪，类似的帖永远会引起口水战，每当我看到XX技术已死,XX技术不行时，我总会去望风，从中或许我们能学到点什么。
    说实话，我没用过GDI+处理任何问题，因此我对它也没有什么感情，但是存在即为道理，既然前辈们都用了，并且在硬件低下的那年代都没什么问题，那么我们是否可以思考下自己的设计方案呢？
      

  21.   

    本来觉得已经没什么可说的了，可是在回几句各位：首先我的观点，GDI+就是比GDI慢，我不喜欢它的设计，你们如果看了我帖子就应该知道，我已经封装了一个类似GDI+的库，我就是使用的它，对我来说它比GDI+合理方便快。那些说我不会用GDI+的可以闭嘴了，我不喜欢当然不会用它。尽管如此，我不觉我比你GDI+用的差，虽然我还是不用它。存在即合理（或者道理），此话的不合理已经无需多言了，一切存在的都有道理，已经没有不合理的东西了，其实这是废话。类似的有，一分钱一分货，贵的自然好，那买东西都不用挑了，根据承受能力，选个价格就完了。有本书，《精通GDI+编程》LZ可以看看——这本书我有，我对GDI+还是了解一点点。