In 1.4 (or perhaps 1.4.1?), the implementation of Toolkit.sync() was changed on Windows to add the necessary functionality of flushing the DirectX pipeline. As of 1.4, we started issuing DirectDraw commands (and as of 1.4.1, we added on Direct3D commands as well). These commands tend to be buffered up in the pipeline of the graphics accelerator and actually executed sometime later. This means that if the user requests rendering synchronization, we must flush the DirectX pipeline. The best way I know of for doing that is to call ddraw.Lock() on the screen.

The problem with locking the screen is that it results in flickering artifacts; see bug 4409306 for more information on this problem.

Some of the artifacts that are noticeable due to scree locking are:
- occasional screen flashing (not sure why this is; seems to be an issue embedded in the OS or ddraw itself)
- mouse cursor flashing (especially on win2k and XP on graphics cards that do not support hardware cursors for the drop-shadow and color effects that tend to be prevalent on those OSs)
- fading menu flickering
- tooltip flickering
The main cause of the flickering (as further described in 4409306) is the inability of GDI to access the screen when it is locked, thus animating effects such as the fading menus are not drawn at all during those frames when GDI is locked out.

Although the fix to 4409306 removed the most serious cause of the flickering (copying pixels to the screen using ddraw) by using GDI for screen copies, it did not fix the problem of applications that call Toolkit.sync(), since we still need to call DDraw.Lock in that function. So if applications call that method, especially on a regular basis (as an animating application might do) they will see this flickering effect.