-
Bug
-
Resolution: Fixed
-
P3
-
5.0, 6
-
b62
-
generic, x86
-
windows, windows_xp
Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
---|---|---|---|---|---|---|
JDK-2140457 | 5.0u10 | Vaibhav Kulkarni | P3 | Resolved | Fixed | b01 |
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.
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.
- backported by
-
JDK-2140457 Flickering upon resize in Mustang
- Resolved
- duplicates
-
JDK-6204874 Applets comes to flicker in 5.0 when browser is scrolling
- Closed
- relates to
-
JDK-6504460 Regression in backport of flickering-related bug fix
- Resolved
-
JDK-6691181 SunToolkit.disableBackgroundErase() needs to support more components
- Resolved
-
JDK-6558510 Flickering upon resize on X11 platforms
- Closed
-
JDK-6235443 REG:Overlapping a swing app with an AWT app causes flickering in the background swing app on Windows
- Closed
(1 relates to)