JDK-6333613 : Flickering upon resize in Mustang
  • Type: Bug
  • Component: client-libs
  • Sub-Component: java.awt
  • Affected Version: 5.0,6
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: windows,windows_xp
  • CPU: generic,x86
  • Submitted: 2005-10-06
  • Updated: 2010-05-05
  • Resolved: 2005-11-26
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 JDK 6
5.0u10Fixed 6 b62Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
In Mustang, dynamic layout of the AWT toolkit was changed to default
to true. This has caused severe flickering when using the JOGL library
(http://jogl.dev.java.net) when resizing windows containing JOGL's
GLCanvas.

JOGL subclasses Canvas into GLCanvas, which overrides paint(Graphics)
and update(Graphics) in order to prevent the core toolkit from
rendering into the Canvas, since all of the rendering is done via
OpenGL using the JAWT. However, this doesn't disable all of the places
the AWT and Java2D attempt to draw into a Canvas.

The problem is the presence of the default background erasure which is
disabled by specifying -Dsun.awt.noerasebackground=true
(WCanvasPeer.java). Specifying this flag fixes the flickering problem.
However, it is not correct to specify this flag for all applications
since their repainting behavior may vary. For this reason we can't
simply force this flag to true whenever JOGL is being used.
(Applications can do so, but we don't have the option of turning it on
automatically in the JOGL library.)

The best solution would be to disable the erasure of the background on
a per-Canvas basis. I've looked through the related Windows peer code
and due to the use of package-private constructors I don't see a way
to get code in between the Canvas and its WCanvasPeer. One thought I
had was to wrap the WCanvasPeer with another WComponentPeer subclass
which would delegate all operations to the contained WCanvasPeer
except return false for shouldClearRectBeforePaint(). I might be able
to make this work by trying to claim that my workaround class lives in
the sun.awt.windows package, but this seems like a really bad hack.

The best solution I can think of at this point would be to add an API
to the Canvas class like

  public boolean shouldEraseBackgroundBeforePaint();

This API should be documented as having platform-specific behavior
(i.e., may not be consulted on all platforms -- the noerasebackground
property only has an effect on Windows as far as I can tell) and the
implementation of WCanvasPeer should be changed to ask its Canvas as
well as look at the globally-specified property. If either says to not
erase the background, return false from
WCanvasPeer.shouldClearRectBeforePaint().

Since this is a small API and implementation change, does not affect
any existing applications, and solves a serious flickering problem in
a general way, it is low risk and should be able to be fixed in
Mustang.

Comments
SUGGESTED FIX There are 2 places, when the canvas background is painted: 1) AwtCanvas::WmEraseBkgnd(); 2) RepaintArea.paint(component, boolean shouldClearRectBeforePaint): background is painted only if WCanvasPeer.shouldClearRectBeforePaint() returns true. The new method public void disableBackgroundErase(Canvas canvas) is added to SunToolkit. When the method is called, a new flag in WCanvasPeer is set and a new flag in AwtCanvas is set, so that afterwards shouldClearRectBeforePaint() returns false and AwtCanvas::WmEraseBkgnd() does not paint background. webrev: http://sa.sfbay.sun.com/projects/awt_data/mustang/6333613.0
31-10-2005

EVALUATION API for disabling background painting for a given Canvas instance is requested. We decided to implement private API at this stage.
31-10-2005