On 11/20/2015 04:13 AM, Philip Race wrote:
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.
Yes that is exactly what I had in mind.
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.
I ended up with imsage SPI provider for ico. Works fine as wrapper around basic
java's bmp and jpg SPIs
Phil, tahnk you very much for your kind and explaining answer.
I'm crossing fingers for jdk10 to settle those multiplicated resolvers as verifying step #1 is not
(from my small touch) the simplest way to do...
J.
-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
