The next version of Windows, Vista, uses a "Desktop Window Manager" (DWM) to combine the windows on the screen in such a way that effects like tranclucent title bars exist automatically. This is done through using Direct3D textures as the surfaces that applications render to (instead of actual windows on the screen).

Operations that talk directly to the screen defeat this mechanism because the DWM cannot guarantee that the offscreen version of the desktop and windows will coincide exactly with the pixels on the screen. Examples of such operations include using DirectDraw to lock the primary surface (which returns a pointer to the onscreen pixel buffer) and calling GDI's GetDC(NULL) (which returns an HDC which could be used to draw directly onto the screen).

When the DWM detects that such an operation is occurring, it disables itself and Vista renders in a more XP-like way. The effect to the user is a momentary flash of the desktop and all windows are repainted with opaque title bars. Thereafter (for the life of the offending process), all windows lack the translucency and warping effects that the DWM would typically use. Once the process exits, there is another flash/repaint and the DWM is back in action.

In pre-Mustang releases, we performed operations such as these at startup time (for example, our initialization of DirectX would Lock/Unlock the primary surface just to test its validity), which causes the DWM to punt as soon as a Java app is started.

As of Mustang, we no longer perform such operations at startup. This means that you can run a desktop Java app that looks good on Vista; title bars are still translucent and the DWM is still operational. However, we still may execute such operations upon demand internally.

One example is Toolkit.sync(). In 1.4.*, we added the capability to sync() to flush the DirectX pipeline, which is necessary to avoid buffering up DirectX requests faster than they can be handled by the graphics card. One effective way to flush these commands is to Lock/Unlock the primary surface, so that's the way we made it work. In a later tweak, we limited the lock to a small region of the screen (to avoid flashing artifacts with various GDI rendering operations), but we're still taking a lock on the onscreen pixels.
This causes the DWM to punt for any Java application that calls sync().

In Windows Vista (I used build 5231, but presumably any version with DWM will behave the same) run the attached application, SyncTester. There are two buttons in the window. Ignore the "AWT Frame" button (I added that just to make sure that other functionality did not force a DWM punt). Click on the "sync" button and watch the flash/repaint artifact occur. We've cause the DWM to punt because we've called Lock/Unlock on the desktop.