C++ GUI 开发 - 位图与矢量图形 CPU 使用率
我目前正在为一些用 C++ 制作的音频应用程序（使用 Juce 框架）设计和开发 GUI。
到目前为止，我一直在尝试使用位图图形来创建自定义滑块和转盘，通过使用“胶片条”样式图像来为组件设置动画（这意味着当用户与滑块交互时，它会触发一种改变胶片偏移的方法） - 剥离图像以更改组件外观）。根据原始图像的大小和“帧”的数量，CPU 使用率水平会发生相当大的变化。
首先，就 CPU 消耗而言，最有效的位图文件格式是什么？目前我正在使用 PNG 图像。
其次，对于此类图形组件使用矢量图形会更有效吗？我了解位图和矢量图形之间的主要区别，但我没有找到任何有关它们在 GUI 交互方面的 CPU 使用级别的信息。
或者 CPU 使用率是否取决于所使用的特定方法/函数/库/框架？
谢谢！
I'm currently in the process of designing and developing GUI's for some audio applications made in C++ (using the Juce framework).
So far I've been playing with using bitmap graphics to create custom sliders and dials, by using 'film strip' style images to animate the components (meaning when the user interacts with a slider it triggers a method that changes the offset of a film-strip image to change the components appearance). Depending on the size of the original image and the number of 'frames', the CPU usage level changes quite dramatically.
Firstly, what would be the most efficient bitmap file format to use in terms of CPU consumption? At the moment I'm using PNG images.
Secondly, would it be more efficient to use vector graphics for these kind of graphical components? I understand the main differences between bitmap and vector graphics, but I haven't found any information regarding their CPU usage levels with regard to GUI interaction.
Or would CPU usage be down to the particular methods/functions/libraries/frameworks being used?
Thanks!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
这些事情中的任何一个都可能影响它。
基于像素的图像越大，可能需要一段时间才能从磁盘上读取它们。压缩类型可能需要更多时间来解压缩。加载时矢量可能需要更多时间来渲染。
话虽这么说，我绝对不希望您选择的图像类型对其性能产生任何影响。由于您没有提供代码示例，因此很难推测除此之外的内容。
一般来说，您会期望图像的运行时成本在加载时发生。所以每当你创建一个图像对象时。如果您在各处创建图像，那么可能会很昂贵。您的胶片可能会重新创建图像，而不是加载一次并缓存它们。
Any of these things could influence it.
Pixel based images might take a while to read off of disk the bigger they are. Compressed types might take more time to uncompress. Vector might take more time to render when are loaded.
That being said, I would definitely not expect that your choice of image type to have any impact on its performance. Since you didn't provide a code example it is hard to speculate beyond that.
In general, you would expect that the run-time costs of the images to happen when they are loaded. So whenever you create an image object. If you create an images all over the place, then maybe its expensive. It is possible that your film strip is recreating the images instead of loading them once and caching them.
在选择位图与矢量图形之前，请调查您的图形处理器是否支持矢量或位图图形。有些东西需要很长时间才能绘制为矢量。
您尝试过双缓冲吗？
这是在显示器（图形处理器）加载另一个缓冲区时写入内存中的缓冲区的地方。
从资源中加载位图一次。将它们存储为内存快照，以避免从格式转换它们的额外成本。
您的图形处理器支持“位块传输”吗？
Blitting 是图形处理器可以复制内存中的矩形区域（位图）并将其与显示前应用可选操作（例如与现有位进行异或）一起显示。
概括：
为了提高渲染速度，只需将文件中的图像转换为位图形式一次。将其存放在某处。根据需要参考此转换后的位图。接下来，研究并实现双缓冲。最后，研究并使用位块传送或位块传送。
其他优化规则也适用于此，例如审查设计、删除需求、循环展开、通过指针传递图像与复制图像，以及通过使用布尔逻辑和卡诺（sp？）图来减少“if”语句。
Before choosing bitmap vs. vector graphics, investigate if your graphics processor supports vector or bitmap graphics. Some things take a long time to draw as vectors.
Have you tried double-bufferring?
This is where you write to a buffer in memory while the display (graphics processor) is loading another.
Load your bitmaps from the resource once. Store them as memory snapshots to avoid the additional cost of translating them from a format.
Does your graphic processor support "blitting"?
Blitting is where the graphics processor can copy a rectangular area in memory (bitmap) and display it along with apply optional operations before displaying (such as XOR with existing bits).
Summary:
To improve your rendering speed, only convert images from the file into a bitmap form once. Store this somewhere. Refer to this converted bitmap as needed. Next, investigate and implement double buffering. Lastly, investigate and use bit-blitting or blitting.
Other optimization rules apply here too, such as reviewing the design, removing requirements, loop unrolling, passing images via pointer vs. copying them, and reduce "if" statements by using boolean logic and Karnaugh (sp?) maps.
一般来说，渲染矢量图形的计算比将位图的矩形区域传输到屏幕要花费更长的时间。但对于基本的 UI 内容，两者都不应该特别密集。
您可能应该做一些分析。也许您重画的频率比必要的要频繁得多。或者也许每次您尝试从中绘制时 PNG 都会被解码。 （我对 Juce 不熟悉。）
对于直接的 Windows 应用程序，我可能会在启动时将矢量图形渲染为设备相关的位图，然后从位图传输到屏幕。使用矢量可以为您提供 DPI 独立性，而从设备相关位图进行位图传输大约是绘制像素块的最快方法。我相信颜色匹配是在渲染到设备相关位图时完成的，因此在屏幕绘图上甚至没有 ICM 开销。
In general, calculations for rendering vector graphics are going to take longer than blitting a rectangular region of a bitmap to the screen. But for basic UI stuff, neither should be particularly intensive.
You probably should do some profiling. Perhaps you're redrawing much more frequently than necessary. Or perhaps the PNG is being decoded each time you try to draw from it. (I'm not familiar with Juce.)
For a straight Windows app, I'd probably render vector graphics into a device-dependent bitmap once on startup and then just blit from the bitmap to the screen. Using vector gives you DPI independence, and blitting from a device-dependent bitmap is about the fastest way to paint a block of pixels. I believe the color matching is done when you render to the device-dependent bitmap, so you don't even have the ICM overhead on the screen drawing.
矢量图形很久以前就被抛弃了——位图图形的性能更高。问题是，您可以将位图发送到 GPU 一次，然后通过简单的副本对其进行永久渲染。
其次，GPU 使用它自己的纹理压缩。我相信 DirectX 是 DXT5，但是当 GPU 看到纹理时，它并不关心你从什么加载它。
然而，现代 CPU 即使具有蹩脚的集成 GPU，在简单的 GUI 渲染方面也绝对没有问题。如果您遇到困难，那么是时候重新审视您正在使用的技术了。也许您的框架很慢或者您对它的使用不是最理想的。
Vector graphics was ditched long ago - bitmap graphics are more performant. The thing is that you can send a bitmap to the GPU once and then render it forever more by a simple copy.
Secondly, the GPU uses it's own texture compression. DirectX is DXT5, I believe, but when the GPU sees the texture, it doesn't care what you loaded it from.
However, a modern CPU even with a crappy integrated GPU should have absolutely no problem with simple GUI rendering. If you're struggling, then it's time to look again at the technique you're using. Perhaps your framework is slow or your use of it is suboptimal.