Bug 1206 - Security: Clear exposed framebuffer after creation and before visibility
: Security: Clear exposed framebuffer after creation and before visibility
Status: RESOLVED FIXED
: None
: Jogl
: JogAmp
: core (show other bugs)
: 2.3.2
: All all
: --- enhancement
: Sven Gothel
:
: 649 1020 1205
: 145
  Show dependency treegraph
 
Reported: 2015-08-28 00:39 CEST by Sven Gothel
Modified: 2015-10-05 08:25 CEST (History)
3 users (show)

:
Type: DEFECT
SCM Refs:
fe0be75545adcec2746f7e0ef53af7c75bfc8fc8 5d0c40061b11909253f07b347db0342b1be38c80
Workaround: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sven Gothel 2015-08-28 00:39:35 CEST
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.
Comment 1 Sven Gothel 2015-08-28 01:18:05 CEST
Known exposed FBOs are:
  - GLJPanel
  - Any used OSX CALayer 

Otherwise it might be overkill to clear all FBOs
right at creation - performance wise?!
Comment 2 Sven Gothel 2015-10-04 02:52:44 CEST
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!
Comment 3 Sven Gothel 2015-10-04 02:53:44 CEST
(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!
Comment 4 Sven Gothel 2015-10-05 08:25:59 CEST
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.