[OpenJDK 2D-Dev] <AWT Dev> Duplicated (or better multiplicated) image-decoder resolvers in openjdk

[Jiri Vanek]

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
>>
>>