使用 Java 高级成像 API 时的性能问题
在我们的项目中，我们使用 JAI 在小程序中显示图像的一部分、旋转图像和基本缩放。我们现在观察到该小程序需要很长时间来加载 - 第一次大约需要 20 秒。但随后，只需要 3 秒（这也相当高）。
JAI 的开发似乎从 2007 年开始就停滞了。至少我在 Java 网站上找不到 2007 年以后的任何下载。
有没有人遇到过加载问题并在 JAI 的背景下解决它们？ 是否有 JAI 的高性能替代方案？ 我们使用的图像是 TIFF 格式，并且它们可以在一个物理文件中包含多个图像。
任何指点都非常感激。
In our project we use JAI for showing parts of an image, rotating an image and basic zooming in an applet. We now observe that the applet takes a lot of time to load - around 20 seconds for the first time. But subsequently, it takes only 3 seconds (which is also quite high).
JAI development seems to have frozen since 2007.Atleast I could not find any download post 2007 on the Java website.
Has anyone encountered loading issues and solved them in the context of JAI ?
Is there a performant alternative to JAI ?
The images we are using are in TIFF format and they can have multiple images in one physical file.
Any pointers greatly appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
第一次应用程序启动（冷启动）可能需要大量时间，因为您需要加载大量库（包括 JAI）。第二次和下一次应用程序启动（热启动）速度更快，因为运行时类缓存在 classes.jsa。
然后，图像处理需要 CPU，并且为了绘制它需要显卡。借助现代计算机，JAI 可以使图像处理（基本操作！）和处理（缩放、平移）变得简单而快速。
自 2007 年完成以来，我们已经开发了带有 JAI + 图像 I/O 的图像审查应用程序，并且缩放和平移速度非常快（1Mp 图像）。图像加载后，处理和处理速度非常快，因此我们在后台线程中加载图像以提高用户体验。
JAI 的问题在于它目前的状态：冻结和/或死亡，但它已经成熟、相当稳定，其他产品（如 Apache Log4J）也有同样的问题，多年来没有新的发展，但人们继续使用它，因为没有其他选择（好吧，洛巴克！）。
JAI 有很多替代品，例如 ImageMagick，但我没有测试它们。
我们在加载和处理图像时非常小心，例如如果可能的话转换为8位/通道，在绘画之前在后台执行操作......
The first application startup (cold startup) could require lot of time, as you need to load tons of libraries including JAI. The second and next application startups (warm startup) are faster as runtime classes are cached in classes.jsa.
Then, the image processing will require the CPU and in order to paint it, the graphics card. With modern computers image processing (basic operations!) and handling (zoom, pan) is trivial and fast with JAI.
We have developed and image reviewing application with JAI + Image I/O and zoom and panning is extremely fast since we finished it in 2007 (1Mp images). After the image is loaded, the processing and handling is very fast, so we load the image in background threads to improve user experience.
The problem with JAI is it current state: frozen and/or dead, but it is mature, quite stable and other products like Apache Log4J have the same issue, no new developments since years, but people continue using it as there is no alternative (well, Logback!).
The are plenty of alternatives to JAI, like ImageMagick, but I didn't test them.
We careful when loading and processing images, like convert to 8bit/channel if possible, perform the operations in background before painting...