-
Bug
-
Resolution: Won't Fix
-
P2
-
None
-
1.2.0
-
generic
-
generic
There is a bug in Swing 1.1.1 FCS RepaintManager. The problem is that the
getOffscreenBuffer method keeps a cached offscreen buffer which will not
be erased, if reused. This can lead to redraw problems as the new content
is drawn on top of the old an blitted onscreen. A workaround is to derive the
RepaintManager and to override the getOffscreenBuffer method from RepaintManager.
The REAL FIX is to put this code into the original implementation
public Image getOffscreenBuffer(Component c, int proposedWidth, int
proposedHeight)
{
Image offscreenBuffer = super.getOffscreenBuffer(c, proposedWidth, proposedHeight);
// Erase the image in case we are reusing a previously
// allocated double buffer
Graphics g = offscreenBuffer.getGraphics();
g.clearRect(0, 0, proposedWidth, proposedHeight);
return offscreenBuffer;
}
Problems shows up as well in JDK 1.2.x and 1.3 ea
stefan.schneider@eng 1999-11-19
Comments from the bug submitter in regards of the response including closing the
bug:
>>For swing, as well as AWT, you MUST have an opaque parent in the containment
>>hierarchy. As this is the case you are guaranteed the offscreen image will be
>>drawn over when needed, and therefore it isn't necessary to clear it out
>>every
>>time it is accessed.
We do have an opaque parent in the containment hierarchy. However, in
very rare situations, the RepaintManager was reusing the offscreen image
when drawing a transparent component whithout drawing the parent
hierarchy first. This happened when switching targets between radio
buttons and edit fields. In case you are asking: We are not using
_paintImmediatey in our code.
>If you do not have an opaque parent, then comes the
>>issue
>>as to what color should be used? The same color will not work for all
>>components. We feel it is better to have the current behavior, as it will be
>>easier for developers to realize what the problem is, then if some obscure
>>color where used.
In case the RepaintManager is reusing an offscreen image, it should
initialize it to the same state as if it was new. Reusing the image is
done for performance reasons, but it has a functional side-effect, that's
why we consider this a bug. Performance optimizations must not change the
behavior of the optimized code.
getOffscreenBuffer method keeps a cached offscreen buffer which will not
be erased, if reused. This can lead to redraw problems as the new content
is drawn on top of the old an blitted onscreen. A workaround is to derive the
RepaintManager and to override the getOffscreenBuffer method from RepaintManager.
The REAL FIX is to put this code into the original implementation
public Image getOffscreenBuffer(Component c, int proposedWidth, int
proposedHeight)
{
Image offscreenBuffer = super.getOffscreenBuffer(c, proposedWidth, proposedHeight);
// Erase the image in case we are reusing a previously
// allocated double buffer
Graphics g = offscreenBuffer.getGraphics();
g.clearRect(0, 0, proposedWidth, proposedHeight);
return offscreenBuffer;
}
Problems shows up as well in JDK 1.2.x and 1.3 ea
stefan.schneider@eng 1999-11-19
Comments from the bug submitter in regards of the response including closing the
bug:
>>For swing, as well as AWT, you MUST have an opaque parent in the containment
>>hierarchy. As this is the case you are guaranteed the offscreen image will be
>>drawn over when needed, and therefore it isn't necessary to clear it out
>>every
>>time it is accessed.
We do have an opaque parent in the containment hierarchy. However, in
very rare situations, the RepaintManager was reusing the offscreen image
when drawing a transparent component whithout drawing the parent
hierarchy first. This happened when switching targets between radio
buttons and edit fields. In case you are asking: We are not using
_paintImmediatey in our code.
>If you do not have an opaque parent, then comes the
>>issue
>>as to what color should be used? The same color will not work for all
>>components. We feel it is better to have the current behavior, as it will be
>>easier for developers to realize what the problem is, then if some obscure
>>color where used.
In case the RepaintManager is reusing an offscreen image, it should
initialize it to the same state as if it was new. Reusing the image is
done for performance reasons, but it has a functional side-effect, that's
why we consider this a bug. Performance optimizations must not change the
behavior of the optimized code.