• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Drawing to a backbuffer

 
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Ranch Hand
Posts: 1535
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
 
Aaron Roberts
Ranch Hand
Posts: 174
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic