[2752] in java-interest
Re: Repainting delayed
daemon@ATHENA.MIT.EDU (Caskey Dickson)
Thu Oct 12 18:07:31 1995
Date: Thu, 12 Oct 1995 12:29:32 -0700
To: sweh@mpn.com (Stephen Harris), java-interest@java.sun.com
From: Caskey Dickson <caskey@pmi.softaware.com>
At 09:31 AM 10/12/95 +0100, you wrote:
>> Hi Stephen,
>
>Hi Arthur,
> much appreciate the help.
>
>> Try putting a sleep in there so that the event handler has some time
>
<--Stuff deleted-->
>
>Unfortunately this doesn't seem to work. I'd tried this with a sleep(1000)
>and all that resulted was a 10 second delay before the screen updated.
>Just in case it was the async loading of images taking too long, I used
>Jim's MediaTracker classs (quite neat!), and this improves the drawing of
>images, but still doesn't flash symbols :-(
>
>Would it have anything to do with being inside mouseDown() that causes
>the problem (ie are repaint() calls suspended until mouseDown() completes?)
>
>Some more details (if you don't mind reading this far...)
<--Stuff deleted-->
>
>Thanks/rgds
>Stephen
>
Stephen,
(I may be wrong on all of this, it comes from my understanding of X and
Windows repainting.)
I believe your problem with the repaint is that calls to repaint are placed
in your applets message queue. In addition, if there are multiple paint
messages in the queue they are grouped together into one message and placed
at the end of the queue. In essence the call to repaint is a request for
the paint procedure to be called at the next opportunity. Therefore you
change the values of the images ten times then paint them in the final
states. Your repaints are not getting processed until the mouse handler
returns.
One soulution to this (in X or Windows at least) would be to create a custom
message (WM_ANIMATE) which has a parameter of the number of times left to
cycle the animation (for one frame animations such as yours). Each time you
process this message you decrement the counter and re-post the message to
yourself.
The only remaining problem is that it may be the case that all paint
messages are grouped to gether at the end of the queue. There is a way to
force a repaint as soon as possible natively for both X and Win but I do not
know if that is available in java.
The problem with sleep is that sleep suspends the entire thread (inside of
which is your animation proc. and your paint proc.) thereby suspending your
repaints.
This bit of code like substance demonstrates the concept except you need to
replace the explicit call to animate with a call to place a message in your
applets message queue.
Something like this would do.
...
case WM_ANIMATE:
randomize_images;
repaint(); -- actually queues a message to call paint
sleep(100); -- you want this somewhere to ensure it all doesn't happen
too -- fast
if (wparm > 0) { -- assuming wparm is how the message parameters are passed
send_message(self, WM_ANIMATE, wparm - 1); -- I don't know how this is
} -- actually done in java
...
Although it is overkill the best way to handle all of these type things is
an animation or sprite control thread. If you plan on writing lots of games
you are going to want to write that anyway.
Disclaimer: I am new to java so the syntax is screwed up so please forgive
any mistakes in here. I also don't know what is and is not possible in the
Java awt.
Hope this helps some.
--------------------------------------------------------------------------------
Caskey Dickson caskey@pmi.softaware.com
Director of Programming 818.542.3820
PerfectMarket Inc. (fax)818.542.3837
--------------------------------------------------------------------------------
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
