C# GDI+/System.Drawing.Graphics - 创建缓冲区并手动位图传输?

发布于 2024-10-24 22:52:13 字数 366 浏览 3 评论 0原文

我正在创建一个 cad 查看器,它可以处理非常大的图像文件,并且我正在尝试对其进行优化,以获得尽可能高的帧速率和尽可能低的内存占用。

它使用 GDI+ 渲染到面板上。

它当前的缺陷在于图像渲染。我使用的一些文件特别大(8000x8000 像素)的参考图像。我优化了内存使用,仅在它们可见时加载它们,并在它们不可见时丢弃它们。这减少了程序内存不足的可能性,但也防止了图像被频繁加载和卸载;然而渲染图像本身(context.DrawImage)仍然会带来非常大的开销。

我现在正在探索将图像传输到某种较小的缓冲区中的方法,渲染此(通常要小得多)缓冲区,然后在缩放级别显着变化时刷新/重建它。

问题是,我在 GDI 中找不到任何相关规定。谁能建议我如何实现它?

I'm creating a cad viewer which deals with very large image files and I am trying to optimise it for as high a framerate and low a memory footprint as possible.

It uses GDI+ for rendering onto a panel.

It's current flaw is with image rendering. Some of the files I'm using reference images which are particularly big (8000x8000 pixels). I've optimised the memory usage by only loading them when they become visible and disposing of them when they're not. This reduces the chance of the program running out of memory but prevents the images from being loaded and unloaded too often; however rendering the images themselves (context.DrawImage) still carries a very large overhead.

I'm now exploring ways of blitting the images into a smaller buffer of some sort, rendering this (generally much smaller) buffer, and then refreshing/rebuilding it when the zoom level changes significantly.

The problem is, I can't find any provision for this in GDI whatsoever. Can anyone suggest how I could achieve it?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

妄司 2024-10-31 22:52:13

我不认为 GDI 是为图像的高速更新而设计的。如果您尝试滚动图像并跟踪鼠标的每次移动,请尝试移动图像的各个部分并填充移动所打开的空间。本质上是重用了程序员在 CPU 速度较慢且 RAM 较小时平滑滚动/平移图形时使用的技巧。

I don't think GDI is designed for such high-speed updates of images. If you are trying to scroll the image, and tracking the mouse with each move, try to shift sections of the image and fill in the space opened up by the shift. Essentially reuse the tricks that programmers used when smoothly scrolling/panning graphics at a time when CPU's are slow and RAM is small.

那小子欠揍 2024-10-31 22:52:13

如果您正在创建需要高帧速率的新图形应用程序并正在寻求建议,那么我建议放弃 GDI+ 并使用 WPF。 WPF使用硬件加速并支持保留模式图形;与 GDI+ 相比,它的性能要好得多,工作量要少得多。

如果存在禁止 WPF 的某些限制,请在您的问题中进行解释。这是相关的,因为此类限制也会影响 GDI+ 绘图。

If you're creating a new graphics application that needs a high framerate and are looking for suggestions, then I suggest abandoning GDI+ and using WPF. WPF uses hardware acceleration and supports retained-mode graphics; this has much better performance for less work than GDI+.

If there is some limitation that forbids WPF, please explain it in your question. This is relevant because such limitations can also impact GDI+ drawing.

纸伞微斜 2024-10-31 22:52:13

GDI Binned 有利于 Direct3D,因为 3D 元素无论如何都会进入方程式。图像变成单个缩略图和更大的图块,根据需要加载/加载。

GDI Binned in favour of Direct3D as 3D elements came into the equation anyway. Images turned into single thumbnails and larger tiles that are loaded in/out as required.

羁客 2024-10-31 22:52:13

我在开发自己的 GIS 应用程序时遇到了类似的问题。我为此找到的最佳解决方案(即使使用 WPF 时)是平铺大图像并仅显示可见部分。也就是说,我会切换到 WPF,不仅是因为上面答案中给出的原因,而且还因为它提供了良好的成像支持。有关详细信息,请参阅链接

I faced a similar problem when developing my own GIS application. The best solution I found for this (even when using WPF) is to tile big images and display only the portions that are visible. This is being said, I would switch to WPF not only for the reasons given in the above answers but also for the good imaging support offered. See this link for more information

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文