United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-4978963 : onscreen objects flicker when apps on Windows call Toolkit.sync()

Details
Type:
Bug
Submit Date:
2004-01-15
Status:
Closed
Updated Date:
2004-06-09
Project Name:
JDK
Resolved Date:
2004-01-26
Component:
client-libs
OS:
windows_nt,windows_xp
Sub-Component:
2d
CPU:
x86
Priority:
P3
Resolution:
Fixed
Affected Versions:
1.4.0,1.4.2,1.4.2_02
Fixed Versions:
1.4.2_05 (05)

Related Reports
Backport:
Duplicate:

Sub Tasks

Description
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.

                                    

Comments
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
                                     
2004-01-15
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


                                     
2004-07-08



Hardware and Software, Engineered to Work Together