JDK-5008179 : Regression: Synchronization change to SwingSet2 causing repaint problems
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 1.5.1
  • Priority: P3
  • Status: Closed
  • Resolution: Cannot Reproduce
  • OS: windows_nt
  • CPU: x86
  • Submitted: 2004-03-04
  • Updated: 2005-03-16
  • Resolved: 2005-03-16
Related Reports
Relates :  
Relates :  
Note: This only appears currently in Swing's dragonfly workspace.

Note: This was seen on a dual processor machine
      Windows NT 4

It appears that the fix to 4463500 has introduced painting problems in SwingSet2. To reproduce, try the following:

- Launch the SwingSet2 demo and Switch to the ColorChooser demo
- Allow the bezier animation to begin
- Drag another window across the SwingSet2 window
- Notice that the areas outside the bezier animation (such as the toolbar) are damaged but do not repaint

EVALUATION Name: apR10262 Date: 03/23/2004 This happends because of thread racing. On multy processor machines main tread is blocked sometimes by bezier animation tread. ====================================================================== After the putback of 4967886 this is no longer reproducible. The theory behind this is as follows: The problem seems to have resulted from the fact that AWT paint requests are serviced at a lower priority than Swing paint requests. In SwingSet2, the Bezier animation thread was likely scheduling Swing paint requests so frequently that the AWT paint requests were being starved. As a result, areas damaged by covering/exposing weren't being repainted. ###@###.###'s fix to 4967886 sees that native exposes are handled in a much better manner. Either the damaged areas are immediately painted from the backbuffer, or they are handled with the same priority as Swing paints. As a result, this problem has dissapeared! ###@###.### 2005-03-16 18:55:18 GMT