JDK-4919780 : JFrame doesn't refresh after screen-saver with different display-mode was active
  • Type: Bug
  • Component: client-libs
  • Sub-Component: 2d
  • Affected Version: 1.4.2_01
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows_xp
  • CPU: x86
  • Submitted: 2003-09-09
  • Updated: 2003-09-19
Description

Name: gm110360			Date: 09/09/2003


FULL PRODUCT VERSION :
java version "1.4.2-beta"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2-beta-b19)
Java HotSpot(TM) Client VM (build 1.4.2-beta-b19, mixed mode)


FULL OS VERSION :
Microsoft Windows XP [Version 5.1.2600]

EXTRA RELEVANT SYSTEM CONFIGURATION :
graphic adapter: ATI Technologies Inc. RAGE 128 PRO AGP 4X TMDS (32 MB RAM)


A DESCRIPTION OF THE PROBLEM :
Open a JFrame in one display mode (my example: 1024x768 32 Bit) and configure your screen saver with a different display-mode (my example: 1024x768 16 Bit)(in windows XP try the 3D Flowerbox screensaver).

Now wait, until the saver starts (or press preview in display-settings). Then move your mouse: the screen saver stops and the whole JFrame refreshes its content. Then press a Button, that starts a modal JDialog: the dialog repaints but the JFrame in the back does not! Even if the modal JDialog will be closed the JFrame does not repaint! The repaint-mechanism of the JFrame is broken until the Frame will be resized. After this the repaint works well again.

With JDK1.4.1 the repaint of JFrame hasn't any problems.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
see Description and use the little example program.


REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

class BlankerTest extends JFrame
{
    public static void   main (String[] args)
    {
        BlankerTest bt = new BlankerTest();
        bt.show();
    }

    public BlankerTest()
    {
        setLocation(100, 100);
        setSize(800, 600);
        getContentPane().setLayout(new BorderLayout());
        getContentPane().add(new JTree(), BorderLayout.CENTER);
        JButton button = new JButton("Test");
        button.addActionListener(new ActionListener()
        {
            public void actionPerformed(ActionEvent e)
            {
                onTest();
            }
        });
        getContentPane().add(button, BorderLayout.SOUTH);
    }

    public void onTest()
    {
        JOptionPane.showMessageDialog(this, "Test-Dialog");
    }
}

---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
When the screen-saver has the same display-mode as the current desktop, then the repaint of JFrame works!

Other workaround: use JDK1.4.1
(Incident Review ID: 187193) 
======================================================================

Comments
EVALUATION I cannot yet reproduce this on my system - I suspect this is a configuration- dependent problem. We need to get a similar system together (at least one with an ATI card running Windows XP) and see if we can reproduce the problem. ###@###.### 2003-09-11 I was able to reproduce the problem exactly on an XP machine with a Radeon 7500. So far, I've discovered that: - the bug is in 1.4.2-beta (b19) and in 1.4.2 FCS (b28) - the bug is in 1.5.0 through b12, and then gone in b15 - the app flat-out crashes in b13/b14 (somewhere in the Win32OSSD.flush native call) I could close this as "fixed" since it is apparently fixed in the current 1.5 code, but I would like to figure out what the problem was and how it was fixed first. Interestingly, the artifact looks like a deadlock (no rendering to the JFrame after the dialog goes away), but there is no deadlock present in the tests I've run (also, a simple resizing of the window probably wouldn['t recover from a deadlock anyway). ###@###.### 2003-09-12 Further info: the problem appears in the 6/26 build of the java2d workspace, but appears fixed in the 7/07 build. Because of the break between these two builds, it's not clear what all of the changes are that would have caused this problem. We need to regress this further (perhaps with archived awt builds?). The bug is now looking more like a modality-related problem (thus the further interest in chasing it down through the AWT builds). ###@###.### 2003-09-12
12-09-2003