Java repaint not updating
Thus, problem solved, and all access is single threaded.
They go to great lengths to explain this in an article on Swing threading along with a pretty lame excuse for implementing it this way towards the end of the article.
But for heavy systems, where timely updates of data is critical, then pretty much ignore everything you've read about Swing threading before.
Optimisation tricks: It's a shame that multi-threaded access is one of the less well understood parts of Java, since it's got so many good things going for it, and even less so when Sun even document the 'safe rather than sorry' approach.
In this article I enumerate reasons why typical approach to painting in AWT / Swing can result in substantial visual lags, provide examples that demonstrate the problem and propose methods to significantly reduce the drawing latency.
Despite the focus on Java platform, the key ideas can be extended to most modern operation systems and GUI frameworks.
So, there must be a way for OS / framework to invoke our rendering code “from outside”. Inversion of control is only a part of the whole story.
But what if we need — the GUI framework, and low-latency painting for some interactive process that are highly sensitive to delays (like typing in IDE)?Here’s how painting is usually implemented in Swing (and in AWT, with some minor differences): The key point here is inversion of control — the drawing code is not invoked directly, we can only request painting, but it’s up to AWT / Swing subsystem to decide how and when to proceed. The primary reason is how stacking window managers work — most operating systems don’t retain application window content, and if some window is overlapped, a part of the window becomes “dirty” and has to be restored afterwards by the application itself.A similar technique is used by Swing internally to render a hierarchy of lightweight components.In fact, there's a discussion about the issues surrounding AWT threading, and in particular one of my vociferous bugs in 4030718 regarding the retarded behaviour that 1.2 and 1.3 had forcing to be used with any GUI apps.(Nice to see that they've implemented a fix in 1.4, though not using my more elegant implementation suggested in the bug report). They removed when moving from AWT to Swing (because Swing was -- and still is -- hideously slow) as a mechanism to speed up redraws, but then they needed to ensure that threading race conditions didn't kill the UI performance.