BufferedImage的getSubimage性能
我正在开发一个 Java 2D 渲染程序（在 1.6.0_11 上运行），它使用外部图像进行 UI 渲染。 这些大图像同时包含多个 UI 图形部分，我现在使用 BufferedImage.getSubimage() 提取它们。 假设一个普通的桌面系统（没有启用 DirectX/OpenGL 加速），我的问题是：
- getSubimage() 是一个内存高效的调用，因为它共享底层图像数据，但这是否会影响这些子图像的渲染速度Graphics2D.drawImage()？
- 如果图像使用每像素 8 位调色板模式，那么使用 RGBA 模式（例如 4 倍内存）或依赖调色板颜色模型（例如转换时间）的增益/损失是多少？
I'm working on a Java 2D rendering program (running on 1.6.0_11), which uses external images for its UI rendering. These large images contain several UI graphics parts at the same time, which I extract now with the BufferedImage.getSubimage(). Assuming an average desktop system (with our without enabling DirectX/OpenGL acceleration), my questions are:
- The getSubimage() is a memory efficient call, as it shares the underlying image data, but does this affect the rendering speed of these sub images with the Graphics2D.drawImage()?
- If the images use 8 bit per pixel color palette mode, what would be the gain/loss of using RGBA mode (e.g. 4x memory) or relying on the palette color model (e.g conversion time)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
据我所知，
getSubimage(...)不应该对渲染产生任何重大影响。转换图像数据的速度很慢，通常最好尽量避免即时进行转换。
对于图像来说，慢速可以分为两类：
磁盘 I/O 很容易成为最慢的部分。
如果您打算仅使用图像的一部分，那么最好能够仅从磁盘加载图像的一部分。
我的经验是 JAI 更擅长只做真正的事情比标准库的东西更需要。
As far as I know,
getSubimage(...)shouldn't have any significant effect to the rendering.Converting image data is slow and usually it is better to try to avoid doing it on the fly.
With images slowness can be divided to two categories:
And disk I/O can easily be the slowest part.
If you are going to use only part of the image, it would be best to be able to load only part of the image from disk.
My experience is that JAI is better at doing only what is really needed than the standard library stuff.