Quote:Original post by leidegren
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.
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.