I was just trying to solve one question from HEAD FIRST JAVA from 12 chap..A VERY GRAPHIC STORY
The below code is for a simple animation where an oval just shift in the jframe in top left to bottom right direction.
My dobut is it works only when I include a System.out.println statement in for loop of go() method( the one in bold and italics ) If I dont the oval just remains stick to a single position.. Below is the code...
Can anyone please expain why does this happen ?
/* CODE */
[ March 15, 2007: Message edited by: Hardik Raja ]
[ March 15, 2007: Message edited by: Hardik Raja ] [ March 16, 2007: Message edited by: Hardik Raja ]
If you haven't done a typo while copying your code, when you comment the System.out line you're also commenting the panel.repaint(). Remember that a // comment is till the end of line, not the end of the instruction.
Joined: Feb 07, 2006
Originally posted by Joan Horta Tosas: If you haven't done a typo while copying your code, when you comment the System.out line you're also commenting the panel.repaint(). Remember that a // comment is till the end of line, not the end of the instruction.
The repaint() method was not on the same line. I have modified my post.
Animations involve some different ideas. One is learning how Swing renders components. When you call repaint on a component the request goes into a queue. if there are a lot of repaint requests in the queue Swing has the option to group some of these together, ie, to wait and repaint every now and then. When you do a for loop and call repaint in it there are so many repaint requests that Swing doesn't have any time at all to do any repainting. The for loop is the center of all activity until it ends. After the loop ends Swing can do a repaint. Another difficulty with your MyDrawPanel, the graphic component, is that the position variables x and y do not increment unless the paintComponment method executes. That is, unless we have a successful repaint. So if 300 rapid calls to repaint result in Swing having to wait until the furious activity in the for loop ends before it can manage one repaint then these position variables will not have changed very much. This is one of the many potential difficulties of mixing your event code and your rendering code. It is generally better to keep the two separate. The System.out.println calls give enough of a delay that Swing has time to repaint the component. In animations it is customary to provide this small time delay inside animation loops with the aid of a javax.swing.Timer or a Thread. Both can be started and stopped from within event code. The general idea for designing graphic components is to have the component maintain the state of your graphics and be able/ready to render this state at any time. Requests for repaint can come from user–initiated events, animation code or System repaints that are triggered by Swing when your componenet needs repainting. If the state of the component changes as a result the execution of code in paintComponent, ie, event code is inside your painting method(s), bizarre results can manifest. The java tutorial has sections on Swing timers and on threads. Here's a modification of your code that illustrates these ideas. There are many ways to put these things together so experimenting is useful.