JDK-4978963 : onscreen objects flicker when apps on Windows call Toolkit.sync()
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.0,1.4.2,1.4.2_02
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_nt,windows_xp
  • CPU: x86
  • Submitted: 2004-01-15
  • Updated: 2004-06-09
  • Resolved: 2004-01-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
1.4.2_05 05Fixed
Related Reports
Duplicate :  
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.

CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: 1.4.2_05 generic tiger-beta2 FIXED IN: 1.4.2_05 tiger-beta2 INTEGRATED IN: 1.4.2_05 tiger-b36 tiger-beta2 VERIFIED IN: 1.4.2_05

EVALUATION While we need to call DDraw.Lock() to flush the pipeline, it is probably not necessary to lock the entire screen. If we can lock just a portion of it (say, one pixel), then GDI should be able to access the rest of the desktop and there should then be no flickering artifacts for these GDI renderings. The things to check here are: - we still do the right thing (flush the pipeline and synchronize DirectX rendering) - the flickering artifacts go away (Note that it might also be possible to cause a flush by locking on an offscreen surface instead of the primary onscreen surface. But this approach would require more checking on whether it actually worked (it's not clear that it would have the same flushing effect) and would also require more logic to account for situations where we could not create the offscreen locking surface or where that surface was lost. So it seems far simpler for now to stick to locking the screen, but limiting the impact of that lock) ###@###.### 2004-01-15 Verified for 1.4.2_05b02 on Win 2000 Pro ###@###.### 2004-06-09