This is being split off from RT-2365, where the idea was first pitched.
Since 10.4, Mac OS X has provided a native ImageIO.framework for reading and writing images, similar to Java's Image I/O framework. Measurements show that performance of ImageIO.framework can be much better than using the core JDK plugins, especially when producing high-quality thumbnails since support for scaling is built-in and well optimized.
I wrote a small native adapter library under javafxgui/opt/javafxgui-iio that uses ImageIO.framework to load JPEG and PNG images when running on Mac OS X. I decided to punt on GIF images for now since multi-frame GIF images are best handled by our existing Java-level ImageLoader code. Also, ImageIO.framework does not have native support for loading images from URLs using the "jar:" protocol, so I'm punting on those as well.
Here is some initial data showing performance of this approach compared to the existing ImageLoader code using Java's Image I/O framework, for loading a 3888x2592 pixel JPEG image. (Note that these numbers reflect performance on JavaFX 1.0, before we optimized image loading inRT-2362.)
JavaFX 1.0 (unoptimized, using Java's Image I/O framework)
no scaling: 932 ms
scaling [1]: 2352 ms
JavaFX 1.5 (unoptimized, using Apple's native ImageIO.framework)
no scaling: 742 ms
scaling [1]: 74 ms
[1] downscaling to width=100, preserveRatio=true...
Since 10.4, Mac OS X has provided a native ImageIO.framework for reading and writing images, similar to Java's Image I/O framework. Measurements show that performance of ImageIO.framework can be much better than using the core JDK plugins, especially when producing high-quality thumbnails since support for scaling is built-in and well optimized.
I wrote a small native adapter library under javafxgui/opt/javafxgui-iio that uses ImageIO.framework to load JPEG and PNG images when running on Mac OS X. I decided to punt on GIF images for now since multi-frame GIF images are best handled by our existing Java-level ImageLoader code. Also, ImageIO.framework does not have native support for loading images from URLs using the "jar:" protocol, so I'm punting on those as well.
Here is some initial data showing performance of this approach compared to the existing ImageLoader code using Java's Image I/O framework, for loading a 3888x2592 pixel JPEG image. (Note that these numbers reflect performance on JavaFX 1.0, before we optimized image loading in
JavaFX 1.0 (unoptimized, using Java's Image I/O framework)
no scaling: 932 ms
scaling [1]: 2352 ms
JavaFX 1.5 (unoptimized, using Apple's native ImageIO.framework)
no scaling: 742 ms
scaling [1]: 74 ms
[1] downscaling to width=100, preserveRatio=true...