Yes this is really 2d rather than AWT.
Image I/O dates from 1.0 whereas Toolkit.createImage(..) dates from 1.0
They share almost no implementation, what there is that is shared is the
IJG JPEG library.
It would be nice if TK.createImage just delegated to Image I/O.
Some years ago we considered something like this and step #1 was to make
sure
about compatibility and performance and a fair amount of work was done but
we did not have resources to follow up. At this time it could be a JDK10
goal
for step #2 to investigate and decide whether it makes sense.
There are still issues like when or if colour space conversion is done.
I do not off-hand remember if there is any obstacle to icedtea's TK image
support simply "understanding" .ico's since I do not recall any definitive
list in the SE spec of what TK.createImage may (or may not) support.
And you can create an image i/o plugin too but not as a standard plugin.
-phil
On 11/18/15, 9:11 AM, Sergey Bylokhov wrote:
Hi, Jiri.
This question also related to 2d area(cc)
I think it is possible to use the PNGImageReader(spi) instead of
sun.awt.PNGImageDecoder, which will allow automatically handle the
nondefault image formats. But as far as I know there are no plan to do
it in jdk9.
On 30.10.15 16:13, Jiri Vanek wrote:
Hello!
Recently I was doing ico imagereader-spi provider for icedtea-web
(which is javaws (and plugin) implementation for openjdk)
Yes, ico is stupid, but is in web standards so having its support is
just natural. However, providing spi did not solved the problem i was
bugged for.
After small debugging why, I found that eg SunToolkit.createImage and
relatives - which are quite heavily used, do not honour ImageIO SPIs and
are going by its own way:
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/FileImageSource.java#l50
for file
and
http://hg.openjdk.java.net/jdk8/jdk8/jdk/file/687fd7c7986d/src/share/classes/sun/awt/image/InputStreamImageSource.java#l213
for stream
Well maybe its legacy bourden, but it is reimplementing what image SPIs
providers via (apis canDecodeInput[2]) do. Long story short -
reimplementing wheel and duplicated (very duplicated) code.
I wonted to ask, if there are any plans in jdk9 to fix this. If no, what
can I do to make it happen.
Thanx!
J.
[2]
https://docs.oracle.com/javase/7/docs/api/javax/imageio/spi/ImageReaderSpi.html#canDecodeInput%28java.lang.Object%29
https://docs.oracle.com/javase/7/docs/api/javax/imageio/ImageReader.html
