Consider using ImageIO for loading images

[hrj]

We are currently using Toolkit.getDefaultTookkit().createImage() to get an Image instance. The advantage of this is that GIF animations are automatically handled by the Image. One possible disadvantage is that we get the "invalid raster" exception when switching monitors.

Using ImageIO is the recommended approach. But this will require management of animations. There are some tutorials on the web about how to do that.

[hrj]

Note: If and when we use ImageIO, consider calling this:

    javax.imageio.ImageIO.setUseCache(false);

to disable disk caching.

[hrj]

Using ImageIO might help solve https://github.com/UprootLabs/gngr/issues/152

A quick fix might be to try decoding with Toolkit first, and use ImageIO as a fallback when Toolkit can't decode the image.

[apicellaj]

I've been looking at this issue and it seems ImageIO also has issues reading CMYK jpegs. There are some external libraries like TwelveMonkeys that might work, but I don't know if adding extra dependencies is how you want to approach this problem.

[hrj]

@apicellaj The external libraries for ImageIO can be dropped in later; the API remains the same. TwelveMonkeys is certainly a good library and it is modular; we can pick the exact features we need. But I am not sure of its performance; let's take that call later.

If you have ImageIO working with GIF animations, that would be sufficient and awesome :)

[apicellaj]

@hrj I've been using Toolkit.getDefaultToolkit().createImage() to get the image for GIFs and ImageIO.read() for everything else.

I don't have GIF animations loading with ImageIO yet but I feel like I might be close to a solution since I can see all the individual BufferedImages and modify the metadata to change how fast the GIF runs. Unfortunately all of the solutions I've seen appear to use File which I've tried to replace (unsuccessfully) with an OutputStream.

[hrj]

@apicellaj Thanks for looking into it. Getting all of this right is a little tricky (loading, decoding, scaling, clipping, painting, animating in separate thread, error handling). Any change is going to require quite a bit of testing. I think, it is ok to leave this issue aside for now.

[ghost]

If you want to support a compact profile and/or any AWT-free JRE, please keep the source code depending on AWT and Swing into classes separated from the core. Supporting Android will be a nightmare if you don't.

[hrj]

@gouessej Agreed and we do want to abstract out dependency on AWT / Swing, though that is very far off. With our current resources we are focussed on improving the layout engine to an acceptable level. Removing AWT / Swing dependency would have to be done as a separate exercise later.

FWIW, some AWT-free JREs do support headless mode. I am not sure if all of them do, and I am not sure about compact profile and Android.