Stating the obvious, a canvas is some special AWT-component that allows the application to draw into.
The not-so-obvious is that a canvas still has a background that you can set with setBackground. If you set this background to some demonstrative color (lets say: cyan), put the jme3-canvas into another swing-component and resize the window, you can spot this background, because it is always drawn into the buffer, and – to make things worse – it is even drawn TWICE if update() is called. See it yourself by looking into the sourcecode of java.awt.Canvas:
[java]public void paint(Graphics g) {
g.clearRect(0, 0, width, height);
}
public void update(Graphics g) {
g.clearRect(0, 0, width, height);
paint(g);
}
[/java]
one could easily overcome this by setting background to Color(0,0,0,0) but that still means that on every display update – which happens quite often – a transparent rectangle is filled one to two times before the application gets informed that the canvas has been resized. The effect is a visible and unneccesary delay in resizing, because the application will redraw every pixel of the canvas again.
So the obvious way would be to override paint and update in the jme3-used canvas classes with something that doesn’t clearRect the screen.
Unfortunately, i wasnt able to spot them… i tried overriding them in LWJGLCanvas, but that doesnt seem to work. So either java.awt.Canvas.paint() gets somehow called and that call should be eliminated or the canvas derived class – which eluded me – does some unnecessary background painting before the actual rendered image gets copied onto the screen.
Any advise?
Canvas is heavyweight AWT, OpenGL draws directly to it. Its supplied by lwjgl so you probably will have to “improve” the lwjgl code here… I am quite sure the canvas itself has transparent background color and you can define the “shine through” color (when OpenGL has no time to draw for whatever reason) by simply setting the parent component color.