🚀 go-pugleaf

I'm not certain about this, but you might be seeing the traditional 
Microsoft 'graphics performance improver' - the OS will skip a few 
repaints if it gets busy.  I hve noticed similar problems in non-java 
programming environments when there is a heavy load on the system.  

Remember, the heavyweight components all rely on the capability of the 
underlying OS for their visual presentation, and if the system doesn't 
flag the window for a repaint it will stay messed.  However, lightweight 
components (Swing) have more integrated functionality and don't rely so 
heavily on the OS so they might behave differently.  You might learn more 
by testing Swing against AWT component types and looking for differences.  
The 'need a repaint' is probably 'window' based so the best test is 
probably to compare Frame and JFrame.

My usual solution with pure Windows programming is to invalidate the 
problem areas or even a whole window, forcing the OS to perform a 
repaint.  It might help to test by forcing a repaint of your java window, 
something like a 'Repaint' button might work if you can figure out how to 
implement the supporting code without getting into native code issues. If 
you can prove the cause you can probably find an automated solution which 
is acceptable in your finished application.

-- 
pf

In article <7ja1en$om19@forums.borland.com>, kmusser@idisys.com says...
> Before too long there are unpainted spots on the
> Java window, but the DOS box looks perfect.
> 
> I'm seeing this on several NT4-SP3 machines (using
> Sun's JDK1.1.7B and Java 2), and with almost any
> application (no matter how simple), so I presume it
> is a generally recognized issue.
> 
> Is Sun working to improve this?  Does this happen
> on everyone's Windows machines?
> 

-- 
pf