[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-2d-dev
Subject:    Re: [OpenJDK 2D-Dev] <AWT Dev> Duplicated (or better multiplicated) image-decoder resolvers in openj
From:       Jiri Vanek <jvanek () redhat ! com>
Date:       2015-11-24 9:16:21
Message-ID: 56542AE5.8000605 () redhat ! com
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]