Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / GUI / January 2006

Tip: Looking for answers? Try searching our database.

Animation not shown; suspect getGraphics() failing

Thread view: 
chataway - 11 Jan 2006 11:16 GMT
Hey all,

Seems to be same old subject? Maybe, maybe not, but I wonder if anyone
has seen this occur or can suggest any paths I can take to fix the
problem detailed here.

I have an AWT Canvas panel (GameCanvas) for a game which is used to
show the animation. This is shown correctly 99% of the time. However,
on some occurrences the animation is not shown, or bizarrely (but
interestingly) the animation can be shown in a different Canvas
(ChatCanvas) on the same Applet. This seems significant; both Canvas
codes follows standard OO practice and hence the ChatCanvas should not
be able to access the Objects being drawn on the GameCanvas.

The significant part of the GameCanvas is:

   public void repaintNow() {

       // grab the graphics object and force repainting
       Graphics graphics = getGraphics();

       if (graphics != null) {
           update(graphics);

           // TODO remove test snippet
           if (showTest) {
               graphics.setColor(Color.black);
               String testString = "" + System.currentTimeMillis();
               graphics.drawString(testString, 100, 100);
           }
           // end test code

           graphics.dispose();

       } else {

           // report occurrence
           System.out.println("Unable to get Graphics");

       }
   }

This method is being called, a graphic object is delivered from the
(non overridden) getGraphics call, however the draw methods fail.
Turning on the "showTest" parameter fails to show as well. No System
outs are shown on the console.

This problem has only been reported on JVM 1.4 and 1.5.

I am unable to find any relevant bug reports, or consistently reproduce
the problem.

Any suggestions on what the problem could be or any clues about how I
can track down the problem would help.

Kind Thanks for your time
ricky.clarkson@gmail.com - 13 Jan 2006 00:15 GMT
It would be better to override paint(Graphics graphics) to do your
painting, where you would either paint everything that you currently
paint, or draw from an offscreen image that you have painted on (e.g.,
BufferedImage, MemoryImageSource).

I'd never call getGraphics() on a Component directly, that's really for
the internals.  Check the AWT tutorials anyway.  It's been a few years
since I dealt with AWT directly.
hiwa - 13 Jan 2006 00:51 GMT
Using getGraphics() is a bad practice.
See the FAQ of comp.lang.java.gui :
http://groups.google.com/group/comp.lang.java.gui/browse_frm/thread/71cd0c849b12
4569/8aeed5d5340bcdd3#8aeed5d5340bcdd3

chataway - 25 Jan 2006 15:09 GMT
Thanks for the answers, it pushed me in the right direction to find the
solution.

Basically, using getGraphics is the optimum way to produce consistent
animation frame rate in Java (it's called Active Rendering).

The problem in my case was that although I had overriden the
paint(Graphics g) method to ignore repaint calls I was updating the
frame in the update(Graphics g) method (see first post). This caused a
problem in that update(Graphics g) is also called for certain AWT
events, meaning 2 separate threads could be updating the screen
simultaneously, producing undefined results.

The solution was to rename update(Graphics g) to drawFrame(Graphics g),
and not to use update(Graphics g) at all.

Sorted!
hiwa - 26 Jan 2006 05:06 GMT
Is it a correct way of doing active rendering? ...
'D like to hear opinions from experienced people.
chataway - 29 Jan 2006 13:52 GMT
I believe so, I have read up about 5 active rendering tutorials and
they were all based on using getGraphics.

However, in most cases they assume you are using full screen and can
adopt buffering strategies, both not available as an AWT applet.

I'm happy with the results anyway...
hiwa - 30 Jan 2006 09:32 GMT
> However, in most cases they assume you are using full screen and can
> adopt buffering strategies, both not available as an AWT applet.
I think full screen mode is a MUST for using active rendering safely.
Am I wrong?


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.