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

[Philip Race]

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