File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Drawing to a backbuffer

 
Aaron Roberts
Ranch Hand
Posts: 174
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I've written a simple app which shows some graphics on the screen and does some very basic sprite movement. I don't know/understand the best way to redraw each frame though.

What I'm doing now is approximately this -



This works, but it seems like a very 'expensive way' to do the drawing each frame. Is there some way to clear out the bufferedImage without doing a fill? Would it be better to create a new image each time - seems like I'd be moving lots of memory around that way.

I read the article at -

http://weblogs.java.net/pub/wlg/435

and wondered if using a volatile image would be a better way. I'm not using full screen mode. I'm drawing on a JPanel, by overriding its paintComponent method.

Thanks!
 
Craig Wood
Ranch Hand
Posts: 1535
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
 
Aaron Roberts
Ranch Hand
Posts: 174
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey thanks alot for the example!

I didn't have the T6 image in the path you had listed, so I grabbed one from the j2sdk under the applets examples. It looks like a molecule of some sort.

The only difference on my machine was that using a volatile image, the background gets drawn. IE I get a grey box around the pic as it bounces around the screen. The buffered doesn't do this.

It also seems to stutter when I drop the delay down all the way to 10. Its not a jerkiness per se. You can see the pic sliding across at a constant speed and then it hiccups ever so slightly. Would this be the garbage collector maybe?

Regards,
Aaron R>
 
Craig Wood
Ranch Hand
Posts: 1535
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The gray box around your volatile image suggests trouble in this line:

I used the T6 in the tumbling duke image sequence from the sun example index. It has a white background and was being rendered on a white background in the app so I could have had some invisible artifacts. You could try the no–argument repaint to see if it works any better. I may have messed up the clipping rectangle. Please let me know how you do with it.

Did you read Chet's second article? It has some more code and information. I found that re–initializing the volatile image when validate returns VolatileImage.IMAGE_RESTORED (as shown in the articles and api) causes some tail–chasing: the renewed image triggers the IMAGE_RESTORED state.

I was pleased to find that the volatile image never needed to be re–initialized, even when I did some of the things on Chet's list of lost–data causes like launching the windows task manager. And I also could not distinguish any difference in appearance or performance between the volatile and buffered images.

I also observed the uneven motion of the image at high speeds near 10. I think this is caused by Swing adding separate calls to repaint together as they pile up in the event dispatch thread queue.
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic