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
JOGL shall ensure that all framebuffers
which are intended for visible exposure are cleared.
Known exposed FBOs are:
- 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.
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!
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.
- 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.