|
Fastest Graphics Rendering to Screen in Java
Link |
by
on 2009-04-29 18:13:09 (edited 2009-04-29 18:13:41)
|
| I've been trying to get some good framerate with the Graphics in Java, but I've been having trouble with what I've been doing. Originally I was using BufferedImages created in main memory (BufferedImage bufImg = new BufferedImage(w,h,BufferedImage.TYPE_INT_RGB)), and that wasn't very fast for me. So I'm now just using VolatileImage for drawing to, but still... Java's stuff have been pretty crappy so far. I tried using MemoryImageSource, editing the pixels behind it on a frame by frame basis, and just rendering that image to screen, but it still performed a bit slower than the VolatileImage implementation. Maybe I'm doing something wrong. I've been doing drawing to a Canvas component (java.awt.Canvas) and I was hoping to achieve some good performance without having to get the Graphics context straight from the frame itself. I'm really wanting to know how you got the performance you have happening with T-Cell and Java. I'm guessing that good performance is not something that should be so hard, even in Java. |
|
Re: Fastest Graphics Rendering to Screen in Java
Link |
by
on 2009-04-29 20:05:06 (edited 2009-04-29 20:06:40)
|
|
T-Cell uses OpenGL inside the Processing.org framework. The processing.org framework does a lot of the tedious work behind the scenes, like image buffering, working with a camera, using canvases, etc. OpenGL is very efficient at resizing images, that's why I chose it for us in the T-Cell project. If you're doing a lot of pixel manipulation, like a game of life implementation or whatever, I suggest Processing.org. The reason being, you can manipulate each pixel in an image as an array and manipulate them very efficiently as seen here. I agree that good performance graphics shouldn't be so hard as it is in Java. Java UI classes are over complicated in the interest of flexibility, and at the cost of ease to learn. 
|
|
Re: Fastest Graphics Rendering to Screen in Java
Link |
by
on 2009-04-29 20:12:26 (edited 2009-05-08 14:36:07)
|
|
Thanks! I'm definitely going to try using that. I've been wanting something that I could use for graphics with my first programming language (which is where I find my highest productivity). Can't wait to try that out. **Edit** Ah, the pixel manipulation example is just like working with MemoryImageSource pixels, but since it's openGL, it's undoubtedly much faster. As far as the effort for performance with the Java API goes, I can't get anything faster than using a VolatileImage for the buffer on the component, and then blitting that volatileimage to the components graphics context. All my experiments with MemoryImageSource have flopped, and while there's one thing left for me to try, I'm pretty sure VolatileImage is the best thing going for using Sun's stuff. With 7000 image (70 by 70 pixels) draws on a single VolatileImage then blitting to screen, I was still getting over 30 Frames per Second... (redraws prompted with a timer set to fire an event every millisecond). However, I think part of the performance problem lies largely with my use of a Collections datastructure for storing and accessing the image position and velocity data. I noticed this while doing pixel by pixel drawing during the MemoryImageSource tests. I think I'm going to have to play around with just using arrays for everything. Thanks again for the suggestion, I'm still trying to get the hang of working with OpenGL. It's going to be the graphics library of choice for me in the future... I just gotta get a better understanding of matrices. |