Ove*_*own 13 language-agnostic user-interface
所有Stackoverflowers,
我想知道为什么GUI代码负责吸走很多很多cpu周期.原则上,图形渲染远没有Doom复杂(尽管大多数企业GUI会引入大量的橱窗装饰).事件处理层看起来也是一个沉重的代价,但是,一个编写良好的实现似乎应该在具有大量内存/缓存的现代处理器上有效地在上下文之间切换.
如果有人在他们的大型GUI应用程序上运行了一个分析器,或者一个普通的API本身,那么我对瓶颈所在的位置感兴趣.
可能的解释(我想象)可能是:
一些GUI框架比其他框架好得多,所以我想听听不同的观点.例如,Unix/X11系统与Windows有很大不同,甚至比WinForms还要多.
编辑:现在是一个社区维基 - 去吧.我还有一件事要补充 - 我是学校里的算法人员,如果GUI代码中的算法效率低下,他们会感兴趣.然后,它可能只是实现开销.
我一般不知道,但我想在你的列表中添加另一个项目 - 字体渲染和计算.查找字体中的矢量字形并将其转换为具有抗锯齿功能的位图表示并非易事.通常需要完成两次 - 首先计算文本的宽度/高度以进行定位,然后实际在正确的坐标处绘制文本.
此外,今天的大多数绘图代码依赖于剪切机制来仅更新GUI的一部分.因此,如果只需要重绘一个部分,代码实际上会重新绘制幕后的整个窗口,然后只需要实际更新所需的部分.
添加:
在评论中我发现了这个:
我对此也很感兴趣.这不能说,因为如果你没有为你的gfx卡正确的驱动程序,桌面图形渲染GUI仅使用CPU渲染令人难以置信的慢.如果你有gfx-drivers,那么desktop-gfx有点快,但从来没有像directx/opengl应用程序那么快.
这是我理解的交易:今天的每张显卡都支持绘图的通用界面.我不确定它是否被称为"VESA","SVGA",或者它们是否只是过去的旧名称.无论如何,这个界面涉及通过中断做所有事情.对于每个像素,都有一个中断调用.或类似的东西.然而,正确的VGA驱动程序能够利用DMA和其他增强功能,使整个过程减少CPU密集度.
添加2:啊,对于OpenGL/DirectX - 这是今天显卡的另一个特性.它们针对独占模式下的3D操作进行了优化.这就是速度的原因.普通的GUI只使用基本的2D绘图程序.因此,每次想要更新时,它都会发送整个屏幕的内容.然而,3D应用程序会将一堆纹理和三角形定义发送到VRAM(视频RAM),然后重复使用它们进行绘制.他们只是说"把纹理设置#25的三角形设置#38并绘制它们".所有这些东西都缓存在VRAM中,所以这又快了.
我不确定,但我怀疑现代的3D加速GUI(Vista Aero,Linux上的compiz等)也可能会利用这一点.他们可以预先向VGA发送公共位图,然后直接从VRAM重复使用它们.但是,任何应用程序绘制的表面仍然需要每次都直接发送以进行更新.
补充3:更多想法.:)适用于Windows,Linux等的现代GUI是面向窗口小部件(面向Windows的扬声器控制).这个问题是每个小部件都有自己的绘图代码和相关的绘图表面(或多或少).当窗口需要重新绘制时,它会调用其所有子窗口小部件的绘图代码,这些子窗口小部件又调用其子窗口小部件的绘图代码等.每个窗口小部件重绘其整个表面,即使其中一些被遮挡通过其他小部件.利用上述剪辑技术,立即丢弃这些绘制信息中的一些以减少闪烁和其他伪像.但仍然有很多手动绘图代码,包括位图blitting,拉伸,倾斜,绘制线条,文本,填充等.所有这些都转化为一系列putpixel调用,通过剪切过滤器/掩码和其他东西进行过滤.啊,是的,阿尔法混合今天也变得流行,效果更好,这意味着更多的工作.所以......是的,你可以说这是因为大量的抽象和间接.但是......你真的可以做得更好吗？我不这么认为.只有3D技术可能会有所帮助,因为它们利用GPU进行alpha计算和裁剪.
让我们首先说编写库比编写独立代码要困难得多.要求您的抽象可以在尽可能多的上下文中重用,包括您尚未使用的上下文,这使得即使对于有经验的程序员来说任务也具有挑战性.
在库中,编写GUI工具包库是一个着名的难题.这是因为使用GUI库的程序范围很广,需求量非常大.Mr Why和Martin DeMollo不久前讨论了GUI库的要求.
编写GUI小部件本身很困难,因为计算机用户对界面行为的细节非常敏感.非原生小部件永远不会感觉对不对,不是吗？为了使非本地窗口小部件正确 - 事实上,为了使任何窗口小部件正确 - 您需要花费大量时间来调整行为的详细信息.
因此,由于用于创建高度可重用组件的抽象机制所引入的效率低下,GUI很慢,这增加了优化代码所用的时间短,因此花费了大量时间才能使行为正确.