缓冲图像的getSubimage性能

Question

缓冲图像的getSubimage性能

3

我正在开发一个Java 2D渲染程序（运行在1.6.0_11上），它使用外部图像进行UI渲染。这些大图像同时包含多个UI图形部分，我现在用BufferedImage.getSubimage()提取它们。假设一个平均的桌面系统（启用或不启用DirectX / OpenGL加速），我的问题是：

getSubimage()是一种内存高效的调用，因为它共享底层图像数据，但这会影响这些子图像与Graphics2D.drawImage()的渲染速度吗？
如果图像使用每像素8位颜色调色板模式，使用RGBA模式（例如4倍内存）或依赖于调色板颜色模型（例如转换时间）会带来什么收益/损失？

- kd304

事实证明，这是一个有点灰色地带。如果不使用DirectX管道，每次提取子图像需要比拥有单独的子图像花费更多的时间。如果图像是一个需要特殊坐标系统才能呈现的平铺，则差异是显着的。启用DirectX和现代图形卡后，BufferedImage成为受管理的图像 - 存储在视频内存中 - 并利用卡的硬件支持。在这种情况下，子图像和非子图像之间没有显着的区别。 - akarnokd

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- iny · Accepted Answer

据我所知，getSubimage(...) 对渲染不应该有任何显著影响。

转换图像数据很慢，通常最好尽量避免在运行时进行此操作。

使用图像时，速度缓慢可以分为两类：

磁盘I/O
数据处理

而磁盘I/O往往是最慢的部分。

如果您只需要使用图像的一部分，则最好能够仅从磁盘加载图像的一部分。

我的经验是JAI比标准库更擅长仅执行实际所需的操作。