many sprites

[DzzD]

@Nate

I believe JPEG splits the image into 8x8 blocks and does a DCT on each. 640x480 would be 80x60 blocks, or 4800 total DCTs. By your math, that is 134,400 additions and 105,600 multiplies. The method in JPEGDecoder that does the DCT is jpeg_idct_islow, and I have a feeling it uses more operations than you have listed. I am really interested in porting the IFAST DCT algorithm I posted about above.

let me know as I am also interrested

you can probalby win a cupple of ms on decoding directly in the format you need and in removing allocation made for each decompression / preallocating once (pooling) from the code.

I am being having a look on it right now too but ouch this code look… awfull…

[Nate]

Haha, yeah the code is pretty nasty. It almost a line for line port of the Blender C code linked to above. I believe I’ve stamped out all the memory allocations. Any memory allocated should be kept around and reused for next time. Nice part about the SWT code being nearly identical to C code is that it never uses array.length so there is no problem if arrays are bigger than they need to be, and it always initializes the structs (inner classes), so instances of these are easily reused.

I didn’t have much luck porting the IFAST DCT. I plan to try again when I get some free time, but I’m not sure I’ll succeed. Feel free to beat me to it!

I’ve uploaded my latest:
http://n4te.com/temp/JPEGDecoder.java

[DzzD]

NB: just think that an easy optimisation that can be do in critical section can be to replace multidimensional array by single dimensional (it is not an issue in C but in java it is a little botlneck)

EDIT : also when possible and still in critical section it maybe usefull to chnge short/byte array to int array (inded it must NOT be casted when reading it) like :

byte b[]
byte b2=b[n]

should be replaced by

int b[]
int b2=b[n]

[DzzD]

here is what I got with VisualVM seems ( the most consuming method seems different than the one you get with hproof)

[Nate]

Hmm, are you sure you used the latest? I updated it a post or so ago.

[DzzD]

heu… I may have used the original :-X, I ll try yours now

(and as I got it I post it… here is what I got with hrpof and the original JPEGDecoder )
1 64.85% 64.85% 297 300240 sun.awt.windows.WToolkit.eventLoop
2 5.46% 70.31% 25 300586 JPEGDecoder.jinit_d_coef_controller
3 4.80% 75.11% 22 300585 JPEGDecoder$phuff_entropy_decoder.decode_mcu_AC_first
4 3.71% 78.82% 17 300589 JPEGDecoder.jpeg_idct_islow
5 3.71% 82.53% 17 300583 JPEGDecoder.ycc_rgb_convert
6 2.18% 84.72% 10 300582 JPEGDecoder.jpeg_idct_islow
7 1.75% 86.46% 8 300584 JPEGDecoder.jpeg_fill_bit_buffer
8 1.31% 87.77% 6 300625 sun.awt.windows.WToolkit.shutdown
9 1.09% 88.86% 5 300592 java.nio.Bits.copyFromByteArray
etc…

[DzzD]

hehe the last one is really faster

I got 180 jps/sec (40 more than the original)

and you are right the IDCT is now the most cpu consuming

[DzzD]

dont want to break all you effort but I found a new JPEGdecoder wich have far away better organisation in source code, it will be probably a lot easier to optimise this one : http://webuser.fh-furtwangen.de/~dersch/JPEGDecoder/JPEGDecoder.zip

[DzzD]

I just tried the sun propraritary classes com.sun.image.codec.jpeg.JPEGImageDecoder , If I did not do mistake it look pretty good

jpegInput.reset();
		this.spriteImage[0]=decoder.decodeAsBufferedImage();

give this result : “decoding 220jpg / second” (265 jpg/s for raster) with my Applet benchmark test 30/80 more than before, and last but not least give a direct usable bufferedimage (can also provide raster data)

[Nate]

I’ll check out the alternate JPEG decoder. I don’t mind throwing away what I’ve done if something else is better! Edit: The one you found is GPL.

Can you include copying the pixels into a ByteBuffer? This way the benchmark is comparable to JPEGDecoder. The code for this is already written here:
http://n4te.com/temp/Test.java
I assume Sun’s decoder is what is used by ImageIO, so performance will probably be the same (slower than SWT’s decoder). I don’t know if there is a license issue or if it is even possible to have it to make a ByteBuffer instead of BufferedImage.

[DzzD]

@Nate

I assume Sun’s decoder is what is used by ImageIO, so performance will probably be the same (slower than SWT’s decoder). I don’t know if there is a license issue or if it is even possible to have it to make a ByteBuffer instead of BufferedImage.

dont know but I found the performance very nice : I got 80 more jpg / sec in comparaison of toolkit and ibm the lastest JPEGDecoder you post here, also you can build a bufferedimage or a raster, you can get an byte array from a raster in no time.

jpegInput.reset();
byte[] b;
Raster buf=decoder.decodeAsRaster();
b=((DataBufferByte)buf.getDataBuffer()).getData();
ByteBuffer buffer = ByteBuffer.wrap(b);

same result 265 jpg /s

[Nate]

OpenGL needs a direct ByteBuffer though, so you’ll have to copy the byte[]. I do like accessing the byte[] your way better than row by row. I’ve updated my test, but it didn’t make ImageIO faster:
http://n4te.com/temp/Test.java

With the new decoder, it fails to decode your Ken fireball pic and also my test image (bent over next to a plant stake!). I tried it on a third pic (only click if you want to see me drinking frozen lemonade with my nipple ) and it worked. This image is 1280x960. I found it took 211ms to parse. With SWT’s decoder it is parsed in 81ms, with ImageIO 85ms to 140ms. Here is my test for the new decoder:
http://n4te.com/temp/Test2.java
HPROF:

   1 64.90% 64.90%    1407 300051 JPEGDecoder2.ScaleIDCT
   2 17.76% 82.66%     385 300053 JPEGDecoder2.output
   3  8.63% 91.28%     187 300052 JPEGDecoder2.output

I think the IDCT is not as advanced as SWT’s, which seems to do some checks and shortcut if possible. I probably won’t pursue the new decoder further since it seem to be slower and has an unfriendly license. I am impressed with its conciseness though!

I tried Sun’s decoder. I can get it to decode once, but the second time around it fails. This makes little sense to me! Here is the test:
http://n4te.com/temp/Test3.java

[Nate]

I ported the IFAST DCT but I can’t get it to work right. Not sure what is wrong with it. I left the jpeg_idct_ifast method in the latest, which is now here:

http://code.google.com/p/skorpios/source/browse/trunk/skorpios-common/src/com/esotericsoftware/skorpios/opengl/JPEGDecoder.java

I can see a few of the optimizations IFAST is doing, so I duplicated jpeg_idct_islow, called it jpeg_idct_islow2 and managed to removed some shifts and adds. The difference is pretty negligible, but whatever, less is less. :-*

I added the alpha stuff needed to use this to decode my IMG (alpha+JPEG, see IMGDecoder in Skorpios) format. In actual usage in my game, the new decoder loads an IMG file twice as fast as the old ImageIO way. 8) Now its time to test it on Android and then I can get back to my animation system! ;D

[Nate]

I came across this in my Googley adventures…

nothings/stb

Has limited support for JPEG, PNG, BMP, TGA, PSD, and ZLIB. Maybe something there can be lifted.