 image corruption comes from DirectX
I experienced similar problems, but this is not a problem of LimeWire directly or of Java.
This comes from an incorrect rendering by your display driver of DirectX drawing operations: your display driver does not serialize correctly these operations if they are not executed in the main thread of the running app, and some operations are colliding each other in the DirectX driver.
(One possible problem is for example that the bottom of the status bar in LimeWire gets rendered all grey when the window is restored from the SystemTray: this comes from the fact that when the window is restored, it first has no title bar or decoration, and the invalidated area does not count the size of this decoration in the first redraw primitive, then the titlebar is added and queues a second redraw request, but there's a strange effect in the display driver that forgets to fix the invalidated area for the redraw operation, so the whole window is greyed when the titlebar and decoration is effectively drawn, but the interior continues to use the screen coordinates computed without the titlebar. I looked into Java sources to see why this happens, but there's no fault here. This comes from a problem in the display driver when combining GDI and DirectDraw drawing operations: the decoration and titlebar is drawn from User32 which uses GDI, and Java uses DirectDraw for rendering the interior of the window).
This happens with various Java applications, but also with some games and other DirectX applications. There's little you can do to fix all of them, but trying to find a newer display driver that complies to the DirectX specification and does not have this multithreading problem. The Java display really depends on drawing operations being executed in a well-defined order, but some drivers freely swap operations that they think are not depending on each other (this happens with some display cards that have parallel processors and incorrect algorithms in the driver to detect collision).
There's one thing you can do however, if you can't fix the display driver: disabling the use of DirectDraw by Java, when starting the Java VM. Because you use the CVS version, this can be added in the run.bat command used to launch LimeWire. This generally fixes the problem, by forcing Java to use the legacy (a bit slower) GDI draw primitives, which are always guaranteed by Windows to be serialized first in the main thread of your app, and also across other applications using GDI.
It's very unlikely that a display driver will not implement GDI correctly on Windows, simply because these drivers don't have to manage the drawing queue themselves.
Known display cards that experiment this type of display corruption problem in all versions of Java since 1.3.1 (the first one which started to use DirectDraw on the Windows port to implement the portable Java2D API) are some old ATI Rage cards, some notebook display drivers, biprocessor display boards such as 3dFX Voodoo-based boards. This problem becomes more visible with Java 1.4 because Java2D is now used much more often within the Java core libraries to implement AWT and all Swing components.
You can't disable Java2D which is now a fundamental part of Java core libraries, but you can instruct it to not use DirectDraw if your display driver cannot serialize correctly both DirectX and GDI primitives. |