Any created framebuffer exposed to the user (visibility) or 3rd party tool shall be cleared after creation and before exposure. This shall ensure that no user or any 3rd party utility will be enabled to read uninitialized memory. The latter could be content of previous windows or even any arbitrary memory region, depending of the underlying driver. JOGL shall ensure that all framebuffers which are intended for visible exposure are cleared.
Known exposed FBOs are: - GLJPanel - Any used OSX CALayer Otherwise it might be overkill to clear all FBOs right at creation - performance wise?!
It has been observed that on certain setups, e.g. GNU/Linux + X11 + AMD/Mesa, the OpenGL framebuffer is uninitialized and exposes its content even if the NEWT window content has been cleared (Bug 1020). This can be tested via TestGearsES2NEWT '-demo 0', i.e. w/o any active GLEventListener. (commit fe0be75545adcec2746f7e0ef53af7c75bfc8fc8) Hence onscreen GLAutoDrawable need to clear the default framebuffer right after initialization as well!
(In reply to Sven Gothel from comment #2) > It has been observed that on certain setups, > e.g. GNU/Linux + X11 + AMD/Mesa, > the OpenGL framebuffer is uninitialized and exposes > its content even if the NEWT window content has been cleared (Bug 1020). That is Bug 1205, not Bug 1020!
commit 5d0c40061b11909253f07b347db0342b1be38c80: Experimenting w/ no GLEventListener attached to an GLAutoDrawable, e.g. GLWindow (onscreen), GLJPanel (fbo offscreen), indeed on some GL implementations the default framebuffer is uninitialized and hence shows garbage. GLDrawableHelper.setViewportAndClear(..) - Clear framebuffer after setting viewport - Called from: - public final void init(..) - public final void reshape(..) - Method is used independent of GLEventListener, hence this simplifies implementation: removes 'setViewport' criteria for init, display, reshape: it is always performed! Note: We only attempt to help against leaking un-initialized framebuffer content not against user-app faults, we do not clear a 2nd-buffer (double-buffering). Note: We may still be late at resize, i.e. small noisy flickering might be visible. This might be due to lack of proper vsync.