Bug ID: JDK-6415012 REGRESSION: Screen flickers in FullScreen mode when using 6.0

Type: Bug
Component: client-libs
Sub-Component: javax.swing
Affected Version: 6

Priority: P2
Status: Closed
Resolution: Won't Fix
OS: windows_2000
CPU: x86

Submitted: 2006-04-19
Updated: 2011-02-16
Resolved: 2006-05-09

VERSION :
Mustang build 78.

A DESCRIPTION OF THE REQUEST :
The program was written with JDK 1.5.0, and it performed very well in the fullscreen mode, but when I run it with JDK 1.6.0 beta, the problem comes, the screen always blinks.

At first,I thought it was due to the Computer that I use ,it has not a good
configuration,but when I take my program to my friend's computer,which has a very good configuration,it has the same problem as mine.

I remove JDK1.6.0 beta ,and reinstall the JDK1.5.0.and the program run very well.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
the same as JDK1.5.0 - no flicker
ACTUAL -
Run TestFullScreen.class with JDK1.6.0, you will be find that the screen flickers 
REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
Attached seperatly
---------- END SOURCE ----------

Release Regression From : mustang
The above release value was the last known release where this 
bug was known to work. Since then there has been a regression.

EVALUATION Oleg is of the opinion ignoreRepaint was never intended to behave that way. In particular, if you set ignoreRepaint to true, then resize the container you should still get programmatic paint events. In other words, that this worked before is a bug. I'm closing this out as will not fix as it would be very problematic for Swing to try and duplicate buggy behavior.
09-05-2006
EVALUATION As Dmitri says, the easy fix is to pass in a null image observer. That way you avoid triggering a bunch of needless repaints and is really what you want anyway. But that skirts the issue, why is this happening? This regression is the result of the gray rect fix, most specifically Swing now handling paint events for heavy weights. In 1.5, if you invoked repaint on a JFrame, AWT would handle the processing of the paint. In 1.6, Swing handles the processing. This test case is setting ignoreRepaint to true. The docs for this says: * Sets whether or not paint messages received from the operating system * should be ignored. This does not affect paint events generated in * software by the AWT, unless they are an immediate response to an * OS-level paint message. Turns out this is wrong. In 1.5, setting ignoreRepaint to true turns off ALL paint events. In 1.6 because Swing is now handling repaint, and Swing doesn't check the ignoreRepaint property, you get more painting than you previously did, which results in the flicker. One possible fix is to have Swing honor the ignoreRepaint property, that is, repaint would become: if (!ignoreRepaint()) { // schedule paint } But this is a bit problematic in so far as if ignoreRepaint is true, all paint events would only be ignored if you subsequently resized the window. If after setting ignoreRepaint to true the size didn't change, repaint() would be honored. Will talk with AWT guys on this.
02-05-2006
EVALUATION This has nothing to do with full screen mode, I can see the same flickering after modifying the test not to enter FS. And it's reproducible on all platforms. The problem first appeared in mustang b32. I've tracked it to the Swing integration into this build. We have Java2D nighlty builds before and after syncing with Swing's workspace, and the problem the problem appears in the after-the-sync build. (for the record, Java2D dvd archive #415, builds 2005-04-12.mustang.pit.beforeSwingMerge and 2005-04-13.mustang.pit) I think the problem has something to do with component updates caused by the ImageObserver mechanism. It appears that the whole component is momentarily repainted at random times, thus the flickering. If the test is modified pass null as image observer to the drawImage call in gameRender() method, the flickering goes away. The test application has a bunch of issues worth mentioning - new images are created on every frame - those images aren't properly loaded prior to being rendered Since this problem appears to be introduced by Swing putback, it's reproducbile on all platforms/pipelines and thus unlikely to be Java2D-related, reassigning to Swing.
26-04-2006
WORK AROUND Load images once with ImageIO (the loading is synchronous) - do not create new ones on every frame, this hurts performance; pass null as image observer to the drawImage call.
26-04-2006