Jump to content

  • Log In with Google      Sign In   
  • Create Account

[java] Direct rendering speed results ( awt vs java2d )


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
17 replies to this topic

#1 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 20 November 2000 - 03:34 PM

I have finished doning some rough testing of various drawing routings in respect to java direct screen rendering. These were on a pIII700, but I believe most of the routines are memory/bus limited more than anything else, and %80 of execution time was in native methods of either awt or java2d. Ok here are the results all results were from drawing 1200 32x32 tiles ( 4 layers ) on the 640x480 screen. This represents a total of 1,228,800 pixels per frame. Not too shabby. Old style offscreen image + opaque images 20fps@16bit 15fps@32bit MemoryImage 1 + copyarray 11fps@16bit 10fps@32bit MemoryImage 2 + copyarray 2.29fps@16bit 13fps@32bit BufferedImage + drawImage 55fps@16bit 30fps@32bit BufferedImage + copyarray 58fps@16bit 33fps@32bit Buffered + copyarray 16bit 300 tiles( 1 layer ) 142fps So as you can clearly see if you do any direct rendering of images your choice is clear, use BufferedImage. It looks to be 2.5-25x faster than the equivialint awt functions. There are drawbacks. It only runs under the java2d ( java1.1 with j2d or 1.2+ ). To get the best speed you have to write a handler for each DataBuffer type byte, short, unsigned short, and int. Well I''m going to get back to work, just though all you out there might be interested.

Sponsor:

#2 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 20 November 2000 - 08:36 PM

Interesting numbers. It would be greatly appreciated if you could post the code for your tests somewhere and drop a link to it here. What exactely do you mean by BufferedImage + copyarray, do you just copy your tiles using arracopy into the databuffer and then draw the image with drawimage?

Henry

#3 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 12:18 AM

Not quite. When I say arraycopy I use ayyapcopy to blit raw short ot int data into the surface array. With the memory image source you then have to update the imageproducer to key the data update. Under buffered image you get an array into the buffer and you just update it.

If others would like to see the code just shout, if I get enough people I''ll write an article for gamedev. I''m also finishing the helper chlasses so I can do...

main() {
ForcedTimingLoop test = new ForcedTimingLoop( new Component );
test.drawResultsOverImage();
test.run();
}

#4 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 21 November 2000 - 05:52 AM

Ok, thanks, that was what I meant too. You copy the data of the tiles using arracopy into the array that you get from the DataBuffer of the BufferedImage, but you still use drawImage in your paint method to draw the BufferedImage to screen.

Btw, read in the Java2D FAQ that jdk1.4 will feature a new hardware accelerated rendering technique:

http://www.javasoft.com/products/java-media/2D/forDevelopers/java2dfaq.html#accel

Henry

#5 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 06:19 AM

Wow, interesting stuff. Naysayers will be caught off guard when jvm starts exceeding compiled languages in time to market and overall performace. I''m a little upset that they are only planning these enhancements for the win32 platform kinda negates the platform independance thing. I checked the early access area and 1.4 is still not availible yet.

The performace of BufferedImage is more than enough for what I''m trying to do, and with a nice wrapper interface I should be able to run transparently on java1.1 and java1.2+ platforms assuming they are fast enough. I did the math my drawing routines are pushing almost 200 MB/s not that bad for a language most people consider slow.

Now if they could only incude functional mulit-track audio mixing I would be set. Java Media 1.0 looks good I just need to sit down and play with it.



#6 Anonymous Poster_Anonymous Poster_*   Guests   -  Reputation:

Likes

Posted 21 November 2000 - 06:53 AM

Well, since the VolatileImage interface will be available in all implementations of the JDK, I am assuming that they will use it to enhance the rendering speed on Linux and other platforms too. IBM might do it for Linux if Sun ignores that platform.

I am not entirely satisfied with the speeds that you present though. First off, you ran the tests on a very fast computer (wonder what kind of rates I''ll get on my ol'' PII 450). Second, since you can not change the screen resolution from Java you will either require some native code that changes the resolution to 640*480 or your image will be tiny (most people use 800*600 or 1024*768). If you do not want to have native code to change the resolution of the screen and choose to draw a larger image instead, your framerates will probably be divided by approx 2-4 (you will just be able to draw 1 or 2 layers instead of 4).

The combination of a slower processor and being forced to draw a 1024*768 image can lower your numbers a lot. Then the fact that one wants to do AI calculations, play music, handle input etc., all while drawing makes me realize how much I really want that accelerated image interface

Henry

#7 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 06:58 AM

I''m not agains using native code to do things that java is incapable of doing like changin resolution. The program will run fine at 640x480 without native code to switch, but I would love to get scaling for free. I''m going to test these results on my wife''s Cele 450 to see if I''m correct in assuming it''s more memory bound than CPU bound.

Something that some other programs have used that may give almost free scaling is using the buffered image as the texture on a polygon that fills the screen. A little overkill, but it it gets me scaling for free on 3d accelerated platforms I''ll take it.

I''ve only been working on this for a few days now and have anready been able to signifigantly increase my speed, so just give me some more time.

#8 Smoo   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 08:48 AM

Ok since I''ve got .. well no experience with Java2d at all, I''m guessing that when you say oldstyle offscreen vs bufferedImage I''ll take it you mean awt and java2d?

And as anon said, if you could post a link to get the source (when you''re done of course ) that would be cool.

Smoo

#9 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 09:25 AM

Yes oldstyle = awt ( Image + MemoryImageSource )
BufferedImage = java2d ( getRaster().getData() )

I''ll clean up the 6 or so test cases I''ve developed as well as the component fps tester. If I get a chance I''ll also throw in at no additional my handy Debugging class that redirects stdout and stderr to a window at the bottom of the screen.

#10 JasonB   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 10:16 AM

Regarding ''oldstyle''/AWT methods, I''ve found that implementing ImageProducer is faster than using MemoryImageSource. I think by about 20%, but it''s been ages since I''ve actually done a direct comparison.

Don''t think it comes close to the fps rates you''re quoting for Java2d though. I''m impressed.

I came across some code (with source) to change the screen resolution (JNI link to a DLL). I can''t remember where I found it, but I''ll email it to anyone who wants it.

J.

PS. I''d be interested in seeing your code as well.

#11 GKW   Members   -  Reputation: 200

Like
Likes
Like

Posted 21 November 2000 - 11:53 AM

I believe I read that in JDK1.4 you will be able to change screen resolution in fullscreen mode.

I wanrned you! Didn''t I warn you?! That colored chalk was forged by Lucifer himself!

Opere Citato

#12 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 21 November 2000 - 01:46 PM

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.

#13 JasonB   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 November 2000 - 01:55 AM

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.

#14 Smoo   Members   -  Reputation: 122

Like
Likes
Like

Posted 22 November 2000 - 05:35 PM

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

#15 snowmoon   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 November 2000 - 12:37 AM

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.

#16 Aldacron   GDNet+   -  Reputation: 3271

Like
Likes
Like

Posted 23 November 2000 - 01:59 AM

Java Game Programming for Dummies has an excellent little class that implements ImageProducer (I believe they called it DirectImage). By doing it that way you have all sorts of options for creating images. Use one as your back buffer, load in bmps, tgas,pcxs, whatever. And it is fast. I haven''t toyed with it for a while, but I think I''ll pull out my old code and dust it off.

#17 Smoo   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 November 2000 - 04:28 AM

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

#18 JasonB   Members   -  Reputation: 122

Like
Likes
Like

Posted 23 November 2000 - 09:17 AM

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.




Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS