Note that such display corruption also occurs with JDK 1.3.1, but less frequently, because Java Swing components in JDK 1.3.1 are based on AWT which rarely uses Java2D, and this JDK has only an embyonic Java2D implementation which makes little use of DirectX on Windows.
In JDK 1.4, Swing was greatly enhanced to display components with Java2D most of the time, and Java2D has now a very extensive use of DirectX (more precisely its DirectDraw part) on Windows.
There are extensive works in Java to further enhance Java2D and provide better support of DirectDraw on Windows, by using some tricky patches in the way drawing primitives sent to the DirectDraw are queued, to bypass some wellknown bugs in display drivers. The tricky thing is that DirectX and thus DirectDraw has several supported versions in its API, and not all display drivers are available that support the latest DirectX 9 API: many display drivers only support DirectX 7, and don't work properly when DirectDraw is combined with GDI in the same application (this is a serialization problem, difficult to implement in display drivers, because Windows GDI as well as Windows User32 or Shell components do not consistently uses DirectDraw for all their output.
Nevertheless, Java2D's use of DirectDraw is still not completely exempt of bugs, notably when it assumes display driver capabilities which are not always impelemnted in all display drivers. DirectX provides a capabilities API that allows the application using DirectDraw to know if an advanced drawing primitive is supported by the driver. Normally Windows should implement the missing primitives by software using the other primitives supported. But if the DirectDraw application (for example Java2D) selects the hardware acceleration only, to bypass the Windows software emulation, things start to be tricky, as the application must check itself all serialization issues.
One of the problem in Java2D is that it runs within multiple threads, whose synchronization by the display driver is not always consistent.
I think that Microsoft has placed the difficulty of developing display drivers too high, by requiring drivers to support simultaneously GDI and DirectDraw. My opinion is that Microsoft should have better rewritten GDI to use DirectDraw always, so that a display drivers could be written to support only a designated smaller set of DirectDraw APIs, that the core Windows DirectX components should manage and queue directly.
Let's wait for a future DirectX API that will allow simplifying a lot display driver implementations. My opinion is that GDI should now become a complete application of DirectDraw and only DirectDraw if DirectDraw is supported by the display driver (GDI support in display drivers should be left unused in that case).
Note also that you can also avoid the -Dsun.java2d.nodirectdraw=true setting in Java: first try to reduce the display acceleration settings in the Avanced Display Control panel. A Full acceleration means that Windows leaves the driver perform all the drawing APIs it says it supports, even if those APIs are not correctly serialized in the display driver.
The first level just disables the hardware cursor acceleation, further levels disable the bitmap renderers in display drivers, or complex renderers such as the driver's built-in font renderer, the drivers's supported antiscaling smoother, hardware-supported texture/bitmap caching buffers, or hardware supported ICM color converters...
Last edited by verdyp; February 18th, 2004 at 06:27 AM.
|