I tried running the fastest test on my wife''s celeron 450 I was getting 35fps insted of 55fps @16bit. It does appear to be CPU bound, but still not shabby. Anyone know of a way to break this CPU bound drawing routines?

Anyone who would like a zip file of the sources e-mail me eric at snowmoon dot com ( figure it out ) the whole thing is 6.6k.

I''m going to give that ImageProducer trick a try to see if that can spped things up some. I have also found a much more accurate timer, it''s part of the JMF 2.1 the Time class has nanosecond accuracy so that should do just fine. It also have audio/video playback and audio mixing... hopfully this will be included in 1.4 along with some of the other things mentioned here.

Java''s really starting to kick ass.

Check out http://www.gaffer.org and look for TinyPTC. He''s got the source there for about the fastest direct blit to screen that I''ve seen (AWT that is).

I''ve managed to tweak a few frames more per second out of it, but not by much.

Hey JasonB, I downloaded TinyPTC to see what it was and I was just going through the code and something caught my attention. Perhaps you (or anyone else) might be able to illuminate me on this since I''ve never used ImageProducer before.

The only time in the actual code where values are being assigned to the _image var is when it''s created:

_image = Toolkit.getDefaultToolkit().createImage(this);

what I don''t understand is when it where is _image updated since nowhere in the code is it linked to the ImageConsumer so could you (or anyone else who''s seen the code or knows what I''m talking about) explain to me how it gets updated?

My only explanation of this is in the createImage(this) where the this is a pointer to the ImageProducer in which case when the ImageConsumer var is updated, the image is also.

I''m not sure if I made sense there or not... I''m hoping you have a better explanation than the one I came up with.

Thanks,
Smoo

createImage(this)

creates the image with the timePTC class as it''s image producer. If you then look through the update(Object pixels) function. Update calls the necessary ImageConsumer functions to update the image and then calls paint() to put it on the screen.

It''s horrible code, because it changes update''s signature ( normally used by awt ). It attempts to pile so much into this one class you loose sight of what happening. I could be wrong, but run() calls Main(_with,_height), but the example file has it''s function declared main this will not work.

hmm.. still interesting tho.

Thanks for your post snowmoon, it helped

as for the Main(_height, _width) line, true it doesn''t work. Main should have been lowercase.

Smoo

Hi Guys

Thanks for your code, snowmoon. I''ve done some tests and here''s what I''ve found. Note the figures are average frames per second running in a 640x480 window.
The test programs blitTest1-6 are code provided by snowmoon. tinyptc is the code taken (and fixed) from gaffer.org. blitTest7 is snowmoon''s fastest code, modified to display the same test pattern as tinyptc.

On my work computer (which is a dual-processor P800 with 350Mb RAM):

blitTest1 20fps
blitTest2 18
blitTest3 11 (color model appears not to work)
blitTest5 32
blitTest6 55

tinyptc 40
blitTest7 (RGB cm) 55

On my laptop at home, which is a gungy P266 with 64Mb of RAM:

blitTest1 6fps
blitTest2 0.5
blitTest3 2
blitTest5 (won''t run - 32bit color not supported)
blitTest6 12

tinyptc 8
blitTest7 8


It''s interesting to note the difference between tinyptc and blitTest7 on the faster machine.

The difference between tinyptc and blitTest7 is that tinyptc implements ImageProducer to deliver the content, whereas blitTest7 uses a BufferedImage. The loop to generate a static test pattern (ala tinyptc) is exactly the same.

J.