TWL's PNGDecoder now available as standalone JAR

[Matthias]

The PNGDecoder from the TWL - Themable Widget Library is now available as a separate JAR.

JAR: PNGDecoder.jar
Source: PNGDecoder.java

Example usage:

1   2   3   4   5   6   7   8   9   10   11   12   13

InputStream in = new FileInputStream("white_pixel.png"); PNGDecoder decoder = new PNGDecoder(in); System.out.println("width="+decoder.getWidth()); System.out.println("height="+decoder.getHeight()); ByteBuffer buf = ByteBuffer.allocateDirect(4*decoder.getWidth()*decoder.getHeight()); decoder.decode(buf, decoder.getWidth()*4, Format.RGBA); buf.flip(); while(buf.hasRemaining()) {    System.out.printf("%02X\n", buf.get() & 255); }

Have fun

EDIT: The PNGDecoder has been moved into the de.matthiasmann.twl.utils package. A class in the old package is still there and forwards all methods to the new PNGDecoder.

[Riven]

Care to share why we should use the TWL PNGLoader as opposed to ImageIO? Performance? If so, what's the diff?

[Riven]

I just stumbled upon this code:

1   2   3   4

int read = input.read(buffer, 0, SIGNATURE.length);          if(read != SIGNATURE.length || ...) {              throw new IOException("Not a valid PNG file");          }

Isn't it perfectly valid for 'read' not to be equal to 'SIGNATURE.length' ...

Think about network traffic that gets sliced and diced.

Games published by our own members! Check 'em out!

[Matthias]

Thanks Riven, it's fixed in the repository

And the main benefit of this PNGDecoder is the ability to decode into a NIO buffer in OpenGL compatible formats. This avoids unnecessary memory copies. To support NPOT textures it's also possible to specify the stride.

[DzzD]

Thanks Riven, it's fixed in the repository

And the main benefit of this PNGDecoder is the ability to decode into a NIO buffer in OpenGL compatible formats. This avoids unnecessary memory copies. To support NPOT textures it's also possible to specify the stride.

does you built your own zlib ?

( EDIT: in case of I posted some times ago a PNG loader source code here http://www.java-gaming.org/topics/pure-java-png-loader-with-efficient-amp-clear-code/22041/view.html but unfortunatly it does not contain its own zlib, but the nice part is that it can be adapted easily to match any requierement : memory / streaming / decoded format / etc... )

EDIT2:  just looked at it, nice source code

[Matthias]

It uses Inflater from java.util.zip and I did not provide a hook to exchange it with another zlib implementation.

What's that all about custom zlib versions? Are there huge performance gains by using a Java based zlib (which I doubt)? The additional code size is an issue, I want to keep the library small.

[DzzD]

It uses Inflater from java.util.zip and I did not provide a hook to exchange it with another zlib implementation.

What's that all about custom zlib versions? Are there huge performance gains by using a Java based zlib (which I doubt)? The additional code size is an issue, I want to keep the library small.

hum zlib is native code in java and should be pretty fast, it seems to me to be a copy (used often in other project than java jre) of an existing librarie (probably "sun-java-boys" get afraid too to redo it from scratch ), the interresting thing would have be to get better control but also provide a full-cross platform png loader (not dependent on any external libraries)

NB: I just noticed that you only implement paletized PNG ? ( even if it would requiere few lines, this is the only one I did not take the time to implement as it was not yet really requiered for me, I have done some debug/improvments that I will try to post "a day ...")

[Matthias]

The java.util.zip package is part of core J2SE - so that's always available.

What do you mean with only palettized?!? It supports every non interlaced format except 16 bit per component.

[DzzD]

The java.util.zip package is part of core J2SE - so that's always available.

nothing really important just that it is an "external libraries" not a pure java program, I did not care before it was pointed to me too...

but if you would like to take full control on abort decoding / memory usage & performances it may be nice to have one pure java, zlib decompression is probably the part that requiere the most processor and may do allocation here and here but who care...

What do you mean with only palettized?!? It supports every non interlaced format except 16 bit per component.

probably that I may buy glasses... I missed that "if ( bitdepth != 8 )"

[Abuse]

The java.util.zip package is part of core J2SE - so that's always available.

What do you mean with only palettized?!? It supports every non interlaced format except 16 bit per component.

If you removed the dependency upon the java.util.zip package you'd open your library up to being of use to J2ME developers.

Not a criticism as such, just a thought.