JDK-4045781 : exposed/damaged canvases don't always update correctly on win32
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 1.1.2,1.1.7,1.2.0,1.2.2
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic,windows_95,windows_nt
  • CPU: x86
  • Submitted: 1997-04-17
  • Updated: 2001-02-14
  • Resolved: 1999-08-19
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.
Other
1.3.0 kestrelFixed
Related Reports
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Description
canvases don't repaint correctly when exposed on win32 (only --
this problem does not repro on solaris).  the problem is generic
and may involve synchronization of damage with repair.  in the
example code shown below, it is not easy to cause the problem to
occur (it may take a couple minutes of damaging the canvas to get
repaint problems), but that is no indication that the problem is
insignificant.  in fact, it may be responsible for all sorts of
paint problems...

import java.applet.*;
import java.awt.*;

class Foo extends Canvas
{
    public void paint(Graphics g)
    {
        for (int i = 0; i < 100; i += 2)
        {
            g.drawString("this is a test of foo", i, i);
        }
    }

    public Dimension getPreferredSize()
    {
        return new Dimension(100, 100);
    }

    public Dimension getMinimumSize()
    {
        return getPreferredSize();
    }
}

public class test extends Applet
{
    public void init()
    {
        setLayout(new FlowLayout());
        add(new Foo());
        add(new Foo());
        add(new Foo());
    }
}



Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: kestrel FIXED IN: kestrel INTEGRATED IN: kestrel
14-06-2004

EVALUATION This bug occurs less frequently with the fix for oracle's hdc bug (GdiSetBatchLimit(1)). It is *not* a duplicate, however. There is some other threadsynch problem here... jonathan.locke@Eng 1997-04-29 It's definitely a race condition. When expose events occur one at a time, everything repaints hunky-dory. When a bunch of expose events occur in rapid succession, as when the window is dragged off the screen and back on in Win32 with full redraw during drag, this baby tosses its cookies. It looks mildly related to #4081126, but no assertion failures occur. I'm running it on a dual-CPU NT4 box, with 1.1.6 AWT. fred.ecks@Eng 1998-01-26 6/24/1999 sandeep.konchady@eng: This bug is not reproducible on Windows NT 4.0 SP4 with 16-bit color and 1024 x 768 using JDK 1.1.8. Associated bugs reported under JDK 1.1.6/1.1.7 were integrated making this closeable. ------- This bug is reproducible on all Windows platforms. We are using CS_OWNDC on all our components. This means that GetDC always returns the same DC. The problem occurs because Java paints occur on one thread at the same time Windows WM_PAINT messages occur on another thread. Inside Windows, it is setting up the clip region for the paint message and corrupting the DC being used by the Java thread to process Component.paint. Since there is no acceptable place to put a lock to guard against this race, the only solution is to not use CS_OWNDC. robi.khan@eng 1999-08-05
05-08-1999

WORK AROUND None possible. jonathan.locke@Eng 1997-04-29
29-04-1997

PUBLIC COMMENTS AWT Canvases don't always update correctly when damaged by a window with full drag on. jonathan.locke@Eng 1997-04-29
29-04-1997

SUGGESTED FIX We still don't understand this one. jonathan.locke@Eng 1997-04-29
29-04-1997