Duplicate :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
|
Relates :
|
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.
|