[3793] in java-interest
Re: Odd timing on Turkey Day
daemon@ATHENA.MIT.EDU (BC Krishna)
Tue Nov 28 10:47:18 1995
To: irogers@biggun.com, Jim.Graham@Eng.Sun.COM, java-interest@java.Eng.Sun.COM,
irogers@biggun.com
From: BC Krishna <bc@futuretense.com>
Date: Tue, 28 Nov 95 13:39:46 -0500 (GMT)
At 11:00 AM 11/27/95 -0800, ian c rogers wrote:
>On Nov 24, 4:54pm, Jim.Graham@Eng.Sun.COM wrote:
>> Note that this repaint does not necessarily get executed immediately.
>> The repaint method is called "as soon as possible", which means that it
>> is scheduled to have its update method called at some time in the
>> future with as little delay as possible. In fact, all of your
>> "scaledRepaint" calls but the last one may end up ignored as they are
>> all collapsed into one repaint which is performed with your variables
>> set up as per the most recent call to this method.
>
>This explains quite a bit of the odd behavior I've been experiencing. So can I
>call repaint(1) to force a call within 1 millisecond and thus gain tigheter
>control over the animation? I'm guessing there is a caveot to this, what would
>it be?
>
>ian
>
A Windows 95/NT detail. Note that, based on the timing of the repaint
requests, you may end up repainting/exposing more than you intended. For
instance, requests to repaint two disjoint geometries may end up
repainting/exposing the union of the two geometries because the individual
Windows WMPAINT messages may get compressed.
We had the damndest time trying to figure this out.
cheers, bc
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
