# Timing deltas and movment issues

This topic is 4168 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Here's the Java code.
current = System.currentTimeMillis();
while(true) {
prev = current;
current = System.currentTimeMillis();
_delta = current - prev;
timer += _delta;
if (timer >= 1000) { // elapsed?
_fps = count; // update fps
count = 0;
timer -= 1000;
}
_panel.repaint(); // render
count++;
}


Here's a bunch of different trace calculations, they should average about ~1.0 second. delta*fps: 0.8220000000000001 delta*fps: 1.233 delta*fps: 0.886 delta*fps: 1.772 delta*fps: 0.886 delta*fps: 1.772 delta*fps: 3.101 delta*fps: 2.215 I'm having trouble getting the movement math right, I use a constant speed of 60 pixel/s and my intention is to use the time delta to decide the length of each step. theta is the angle in which movement is to proceed, _v is the constant speed, and d is the time delta. _v * d should equal the distance, and sin/cos should account for the angle.
_x0 = _x0 + Math.sin(theta) * (_v * d);
_y0 = _y0 + Math.cos(theta) * (_v * d);


I'm thinking _panel.repaint() isn't a blocking call, and the render thread therefor doesn't time the calculation properly. Because this seems right, but doesn't work. I'm aware of the lack of high-resolution timer in java, as well as the performance implication, but code is still code, and this should work well for a simple 2D application i'm making, but it doesn't. Any takers?

##### Share on other sites
I'm just gonna go a head an answer my own question, with my own theory.

By replacing the _panel.repaint() with _panel.update(_panel.getGraphics()); the problem resolved it self, and my theory that _panel.repaint() isn't a completely blocking call seem true.

the delta*fps ~1.0 second average also improved, as well as the fps which oddly seem to calculate to about 400+, to a more reasonable 60-90.

I hate Java.

##### Share on other sites
Quote:
 Original post by leidegrenmy theory that _panel.repaint() isn't a completely blocking call seem true.

Why did you think it is? The API docs are clear:
Quote:
 public void repaint() Repaints this component. If this component is a lightweight component, this method causes a call to this component's paint method as soon as possible. Otherwise, this method causes a call to this component's update method as soon as possible.

In other words, repaint() schedules the component (or, in the complicated variants, a portion of the component) to be redrawn.

There is a little article from Sun about repainting.

[Edited by - LorenzoGatti on April 24, 2007 10:18:39 AM]

##### Share on other sites
Well, it seems very odd to me that a method call on what appears to be a singel threaded application in fact isn't a blocking call. In such an environment i expect control not to be returned by the calling thead until the actual repaint is completed.

On the same topic about threads, if the timing thread never yeilds, e.g. sleep(>0), the repaint never finnish, and the component is never drawn. So a lot of confusion went into that.

I just didn't cross the API on the specific topic.

##### Share on other sites
Quote:
 Original post by leidegrenWell, it seems very odd to me that a method call on what appears to be a singel threaded application in fact isn't a blocking call. In such an environment i expect control not to be returned by the calling thead until the actual repaint is completed.On the same topic about threads, if the timing thread never yeilds, e.g. sleep(>0), the repaint never finnish, and the component is never drawn. So a lot of confusion went into that.

AWT/Swing has several hidden threads, including one which, sooner or later, renders parts of the window for which repaint() has been called.

The rationale is that many situations and event handlers need a repaint(), just to be safe, so it should be cheap and idempotent, with an hidden, centralized mechanism to manage dirty regions and draw everything only once. Not exposing the user to details of frame rate, buffering, etc. is also useful.

Another common victim of threading problems is the poor event dispatching thread (often the same one who redraws components), which walks all event handlers of the whole application and can get stuck in computationally intensive methods (stalling all subsequent events), not to mention sleep(), wait(), and suspension by a debugger.

##### Share on other sites
Of course all this makes perfect sense, I'm however not that familiar with AWT/Swing internals, it just struck me as odd.

Thanks for shedding some light on the issue.

1. 1
2. 2
Rutin
21
3. 3
4. 4
frob
15
5. 5

• 9
• 13
• 9
• 33
• 13
• ### Forum Statistics

• Total Topics
632593
• Total Posts
3007282

×